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PREFACE 


This manual supplies reference information to 
Network Access Method (NAM) Version 1.8, Communi¬ 
cations Control Program (CCP) Version 3.8, and 
CDCNET Version 1,2 users, typically either pro¬ 
grammers or analysts who are writing a network 
application or who would like to learn more about 
how the various portions of the network fit 
together. 


AUDIENCE FOR THIS MANUAL 

This manual is directed at a programmer or analyst 
who is familiar with subsystem applications pro¬ 
gramming, compiler and assembler programming 
conventions, terminal communication protocols, 
other network software products, and the program¬ 
ming requirements of supported devices. 


This manual describes how application programs 
Interface to the computer network. The NAM 1/CCP 3 
Terminal Interface reference manual describes how 
the terminal user gains access to these applica¬ 
tions. Also, this manual familiarizes the reader 
with the network processing unit (NPU) and the 
Communications Control Program (CCP). Knowledge of 
the NPU and CCP, however, is not necessary to write 
an application program. 


NAM operates under control of the NOS 2 operating 
system for the CONTROL DATA® CYBER 180 Computer 
Systems; CYBER 170 Computer Systems; CDC® CYBER 70 
Computer System models 71, 72, 73, and 74; and 6000 
Computer Systems. 

NAM is the subset of the host computer software 
that provides communication between an application 
program in the host computer and other applica¬ 
tion programs or devices accessing the network's 
resources. 


The Communications Control Program is software that 
resides in a 255x series network processing unit 
that allows a device to access the host computer 
over communications-lines. 


CDCNET is the collection of compatible hardware and 
software products offered by CDC to interconnect 
computer resources into distributed communications 
networks. 


The following manuals are of primary Interest: 


Publication 

CDCNET Conceptual Overview Manual 
CDCNET Configuration and Site Administration 
CDCNET Reference Manual 


ORGANIZATION 

Section 1 introduces the NAM, CCP, and CDCNET soft¬ 
ware. Section 2 describes the protocols governing 
information exchanged for communication between NAM 
and -each application program, and between appli¬ 
cation programs and their connections. Section 3 
describes the synchronous and asynchronous super¬ 
visory messages used by application programs. 
Section 4 describes the language and internal 
interfaces required by an application program. 
Section 5 discusses the application interface pro¬ 
gram statements used by NAM to access the network 
and to send and receive messages. Section 6 dis¬ 
cusses the structure and execution of an applica¬ 
tion program job as a batch or system origin type 
file. Section 7 contains a FORTRAN program using 
AIP; section 8 describes QTRM. 


RELATED PUBLICATIONS 

Related material is contained in the publications 
listed below. Other manuals may be needed, such as 
the hardware, firmware, or emulator software refer¬ 
ence manual for. the devices serviced by a given 
program. Also, communication standards and device 
operating literature can be useful. 

The NOS System Information Manual is an online 
manual that Includes brief descriptions of all NOS 
and NOS product manuals. To access this manual, 
log in to NOS and enter the command EXPLAIN. 


Publication 
Number _ 

60461540 

Guide 60461550 

60460590 


CDCNET Systems Programmer's Reference Manual 

Volume 1, Base System Software 60462410 

CDCNET Systems Programmer's Reference Manual Volume 2, 

Network Management Entities and Layer Interfaces 60462420 

CDCNET Systems Programmer's Reference Manual Volume 3, 

Network Protocols 60462430 
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Publ Icatlon 

Publ Ic ation _ 

CDCNET Systems Programmer's Reference Manual Volume 4, 

Terminal Interface Programs 60462440 

CDCNET Terminal Interface Usage Manual 60461530 

Network Products 

Network Access Itethod Version 1 

Network Definition Language 

Reference Manual 60480000 

Network Products 

Network Access Method Version 1/ 

Communications Control Program Version 3 


Terminal Interfaces Reference Manual 


60480600 

NOS Version 2 Reference Set, Volume 
Introduction to Interactive Usage 

1 

60459660 

NOS Version 2 Reference Set, Volume 
System Commands 

3 

60459680 

NOS Version 2 Reference Set, Volume 
Program Interface 

4 

60459690 


The following manuals are of secondary interest: 


Publication 

Publication 

Number 

Communications Control Program Version 3 
Diagnostic Handbook 

60471500 

COMPASS Version 3 

Reference Manual 

60492600 

COBOL Version 5 

Reference Manual 

60497100 

CYBER Cross System Version 1 

Build Utilities Reference Manual 

60471200 

CYBER Cross System Version 1 

Macro Assembler Reference Manual 

96836500 

CYBER Cross System Version 1 

Micro Assembler Reference Manual 

96836400 

CYBER Cross System Version 1 

PASCAL Reference Manual 

96836100 

FORTRAN Version 5 

Reference Manual 

60481300 

Hardware Performance Analyzer (HPA) 

User Reference Manual 

60459460 

Message Control System Version 1 

Reference Manual 

60480300 

NOS Version 2 

Diagnostic Index 

60459390 

NOS Version 2 

Installation Handbook 

60459320 

NOS Version 2 

Administration Handbook 

60459840 

NOS Version 2 

Operations Handbook 

60459310 
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Publication 

Publication Number_ 


NOS Version 2 

Analysis Handbook 60459300 

Network Products 

Remote Batch Facility Version 1 

Reference Manual 60499600 

TAP Version 1 

Reference Manual 60459500 

2551-1, 2551-2, 2552-2 Network Processor 

Unit Hardware Reference Manual 60472800 


2560 Series Synchronous Communications 

Line Adapter Hardware Maintenance Manual 74700700 

2561 Series Asynchronous Communications 

Line Adapter Hardware Maintenance Manual 74700900 

2563 Series SDLC Line Adapter 

Hardware Maintenance Manual 74873290 


Sites within Che United States can order CDC manuals from Control 
Data Corporation, Literature and Distribution Services, 308 North 
Dale Street, St. Paul, Minnesota 55103. 

Other sites can order CDC manuals by contacting the local country 
sales office. 


This product is Intended for use only as 
described in this document. Control Data can¬ 
not be responsible for the proper functioning 
of undescribed features or parameters. 


If you have access to SOLVER, the CDC online facility for reporting problems, you 
can use it to submit comments about this manual. V/hen SOLVER prompts you for a 
product identifier for your report, please specify NA5. 




CONTENTS 


NOTATIONS 


1. NETWORK PRODUCTS: AN OVERVIEW 1-1 

Computer Network 1-1 

Communications Network 1-2 

Services Network 1-2 

Software Components of the Network 1-2 

Network Access Method 1-2 

Peripheral Interface Program 1-5 

Network Interface Program 1-5 

Application Interface Program 1-5 

Queued Terminal Record Manager 1-5 

Network Definition Language Processor 1-6 

Network Supervisor 1-6 

Communication Supervisor 1-6 

Network Validation Facility 1-6 

Network Utilities 1-6 

Network Dump Analyzer 1-6 

Load File Generator 1-7 

Debug Log File Processor 1-7 

Hardware Performance Analyzer 1—7 

NAM Application Programs 1-7 

CDC CYBER Cross System Software 1—7 

Network Processing Unit and Communications 

Control Program 1-8 

Network Processing Unit 1-8 

Communications Control Program 1-8 

Base System Software 1-8.1 

System Autostart Module 1-8.1 

Service Module 1-8.1 

Host Interface Program 1-8.1 

Terminal Interface Program 1—8.1 

Link Interface Program 1-8.1 

Block Interface Program 1-8.1 

In-Line and On-Line Diagnostics 1-8.2 

NPU Console Debugging Aids 1-8.2 

Performance and Statistics Programs 1-8.2 

Device Interfaces and CDCNET 1-8.2 

Base System Software 1-8.2 

Layer Software 1-8.2 

Interface Software and Gateways 1-8.2 

Network Management Software 1-8.2 

Device Interfaces 1-8.2 

The Packet Switching Network (PSN) 1-9 

NAM Concepts 1-9 

Virtual -Terminals 1-9 

Logical Connections 1-10 

Owning Consoles 1-10 

Network Access Method Operation 1-11 

Application Program Concepts 1-11 

Connection Processing Flow 1-11 

Supported Terminals 1-lA 

2. INFORMATION PROTOCOLS 2-1 

Information Flow 2-1 

Structure Protocols 2-1 

Physical Protocols and Network Blocks 2-1 

Logical Protocol and Physical Blocks 2-1 

Network Data Blocks 2-2 

Transmission Blocks 2-4 

Interactive Terminal Input Concepts 2-4 

Line Mode Operation 2-4 


Block Mode Operation 2-4 

Physical and Logical Lines 2-5 

End-of-Llne Indicators 2-5 

Multiple Logical Lines in One Message 2-5 
End-of-Block Indicators 2-6 

Interactive Terminal Output Concepts 2-7 

Batch Device Data 2-7 

Appllcatlon-to-Applicatlon Input and 

Output Concepts 2-7 

Information Identification Protocols 2-7 

Application Program Message Types 2-7 

Application Block Types 2-7 

Block Buffer Areas ' 2-8 

Block Header Area 2-8 

Block Text Area 2-8 

Connection Identifiers 2-9 

Application Connection Number 2-9 

Application List Number 2-9 

Data Message Content and Sequence Protocols 2-10 
Interactive Virtual Terminal Data 2-lU 

Line Turnaround Convention 2-11 

Interactive Virtual Terminal Exchange 

Modes 2—11 

Normalized Mode Operation 2-11 

Upline Character Sets and Editing 

Modes 2-12 

Downline Character Sets 2-14 

Page Width and Page Length 2-14 

Format Effectors 2-14 

Transparent Mode Operation 2-19 

Applicatlon-to-Applicatlon 

Connection Data 2-23 

Application Character Types 2-23 

Character Byte Content 2-25 

Block Header Content 2-25 

Supervisory Message Content and Sequence 

Protocols 2-25 

Asynchronous Messages 2-36 

Synchronous Messages 2-36 

Block Header Content 2-36 

3. SUPERVISORY MESSAGES 3-1 

Message Mnemonics 3-1 

Message Sequences 3-1 

Managing Logical Connections 3-5 

Connecting Devices to Applications 3-5 

Connecting Applications to Applications 3-16 
Monitoring Connections 3-29 

Terminating Connections 3-30.1 

Managing Connection Lists 3-31 

Controlling List Polling 3-31 

Controlling List Duplexing 3-32 

Controlling Data Flow 3-35 

Monitoring Downline Data 3-36 

Controlling or Bypassing Upline and 

Downline Data 3-42 

Discarding Upline and Downline Data 
on Appllcation-to-Applicatlon 
Connections 3-42 

Discarding Downline Data on 

Devlce-to-Application Connections 3-43 
Discarding Upline and Downline 
Data on a Device-to- 

Application Connection 3-43 


60499500 V 


ix 




Bypassing Downline Data on an 
Applicatlon-to-Appllcatlon 
Connection 3-45 

Terminal Use of User Interrupts for 

Priority Data 3-46 

Controlling Upline Block Content 3-47 

Converting and Repacking Data 3-47 

Repacking Synchronous Supervisory 

Message Blocks 3-49 

Exchanging Transparent Data With Devices : 3-50 

Truncating Upline Blocks 3-50 

Managing CCP Device Characteristics 3-51 

Changing CCP Device Characteristics 3-53 

Effects of Changing Terminal Class 

on CDCNET 3-63 

Requesting CCP Device Characteristics 3-63 

Changing CDCNET Terminal Characteristics 3-65 

Converting Attributes 3-68.1 

Requesting CDCNET Terminal 

Characteristics ■ 3-68.4 

Host Operator Commands 3-69 

Host Operator Interface 3-73 

Host Shutdown 3-78 

Error Reporting 3-79 

4. USER PROGRAM INTERFACE DESCRIPTIONS 4-1 

Language Interfaces 4-1 

Parameter List and Calling Sequence 

Requirements 4-1 

Predefined Symbolic Names 4-1 

Predefied Symbolic Values 4—2 

COMPASS Assembler Language 4-2 

Application Interface Program 

Macro Call Formats 4-2 

Field Access Utilities 4-11 

Compiler-Level Languages 4-12 

Application Interface Program 

Subroutine Call Formats 4-12 

Field Access Utilities 4-12 

Queued Terminal Record Manager 

Utilities 4—14 

Internal Interfaces 4-16 

Application Interface Program and 

Network Interface Program Communication 4-16 
Workllst Processing 4-16 

Parallel Mode Operation 4-17 

Other Software Communication 4-17 

5. APPLICATION INTERFACE PROGRAM 

CALL STATEMENTS 5-1 

Syntax 5-1 

Network Access Statements 5-1 

Connecting to Network (NETON) 5-1 

Disconnecting From Network (NETOFF) 5-4 

Network Block Input/Output Statements 5—4 

Specific Connections 5-4 

Inputlng to Single Buffer (NETGET) 5-4 

Inputlng to Fragmented Buffer 

Array (NETGETF) 5-6 

Outputlng From Single Buffer 

(NETPUT) 5-7 

Outputlng From Fragmented Buffer 

Array (NETPUTF) 5-8 

Connections on Lists 5-10 

Inputlng to Single Buffer (NETGETL) 5-10 

Inputlng to Fragmented Buffer 

Array (NETGTFL) 5-12 


Processing Control Statements 5-14 

Suspending Processing (NETWAIT) 5-14 

Controlling Parallel Mode (NETSETP) 5-15 

Checking Completion of Worklist 

Processing (NETCHEK) 5-16 

Initiating Special AIP Functions 

(NETFUNC) 5-17 

6. CHARACTERISTICS OF AN APPLICATION PROGRAM 6-1 

NOS System Control Point Facility 6-1 

Batch Job Structure 6-1 

Commands 6-2 

Job Identification b-3 

Program Content • 6-3 

Program Execution Through lAF 6-3 

Types of Application Programs 6-4 

Disabled 6-5 

Unique Identifier 6-5 

Privileged 6-5 

Request Startable 6-6 

Have More Than One Copy (on any One Host) 6-6 
Restricted or General Access 6-6 

Mandatory or Primary 6-6 

Debugging Application Programs 6-6 

Fatal Errors 6-6 

Debugging Methods 6-6 

Debug Log File and Associated 

Utilities 6-6 

Statistical File and Associated 

Utilities 6-15 

Dependencies for Program Use 6-16 

Memory Requirements 6-17 


7. SAMPLE FORTRAN PROGRAM 7-1 

Configuration Requirements 7-1 

Job Command Portion 7-1 

Program Portion 7-1 

Program Output 7-1 

8. QUEUED TERMINAL RECORD MANAGER 8-1 

Network Information Table 8-1 

Subroutines 8-26 

Initiating Network Access (QTOPEN) 8-26 

Command to QTRM (QTCMD) 8-27 

Notification of Break Indicator 

Mark (cc=l) 8-27 

Notification of User/Application 

Interrupts (cc=2) 8-27 

Notification of Inactive Connections 

(cc=3) 8-27 

Support of NAM K-display (cc=4) 8-28 

Notification of Initial Connection 

Requests (cc=5) 8-28 

Store Address in Parm-addr Field 

(cc=6) 8-28 

Automatic Processing of User 

Breaks (cc=7) 8-28 

Selective Polling of Connections 

for Data (cc=8) 8-28 

Application Processing of NETON 

Rejects (cc=9) 8-28 

Application Processing of ERR/LGL 

Supervisory Messages (cc=10) 8-29 

Sending Data (QTPUT) 8-29 


X 


60499500 V 



Obtaining Data or Connection 


1-5 

Network Access Method Components 

1-12 

Status (QTGET) 

8-30 

1-6 

Typical Application Program 


Sending a Synchronous Supervisory 



Processing Flow 

1-13 

Message (QTTIP) 

8-31 

2-1 

Physical and Logical Information 


Linking an Application to Another 



Structures 

2-2 

Application (QTLINK) 

8-31 

2-2 

Block Reassembly Points 

2-3 

Ending a Single Connection (QTENDT) 

8-32 

2-3 

Applicatlon-to-Application Connection 


Loaning a Single Connection (QTLEND) 

8-33 


Data Exchanges 

2-24 

Issue Supervisory Messages (QTSUP) 

8-34 

2-4 

Application Block Header Content for 


Send Supervisory Message (smc=0) 

8-34 


Upline Network Data Blocks 

2-26 

Send Flow Control Break (smc=l) 

8-34 

2-5 

Application Block Header Content for 


Change Input Character Set (snic=2) 

8-34 


Downline Network Data Blocks 

2-30 

Truncate Data (smc=3) 

8-34.1 

2-6 

Supervisory Message General Content, 


Send Application Interrupt (smc=4) 

8-34.1 


Asynchronous Messages and 


Change to Full-Duplex List 



Synchronous Messages of Application 


Processing (srac=5) 

8-34.1 


Character Type 2 

2-33 

Change to Half-Duplex List 


2-7 

Supervisory Message General Content, 


Processing (smc=6) 

8-34.1 


Synchronous Messages of Application 


Turn List Processing Off {siiic=7) 

8-34.1 


Character Type 3 

2-35 

Turn List Processing On (smc=8) 

8-34.2 

2-8 

Application Block Header Content for 


Send K-display Message (smc=9) 

8-34.2 


Upline Supervisory Messages 

2-37 

Log NAM Dayfile Message (smc=10) 

8-34.2 

2-9 

Application Block Header Content for 


Alert Host Operator (smc=ll) 

8-34.2 


Downline Supervisory Messages 

2-39 

Log Operator Entries (smc=12) 

8-34.2 

3-1 

Supervisory Message Mnemonic 


Change Inactivity Timer (smc=13) 

8-34.2 


Structure 

3-1 

Ending Communication With the 


3-2 

Devlce-to-Applicatlon Connection 


Network (QTCLOSE) 

8-34.3 


Supervisory Message Sequences 

3-b 

Output Formatting and Editing 

8-35 

3-3 

Connection-Request (CON/REQ/R) 


Format Effectors 

8-35 


Supervisory Message Format, 


Display-Code Output Editing 

8-35 


Devlce-to-Application Connections 

3-7 

Output Queuing Using QTRM 

8-36 

3-4 

Connection-Accepted (CON/REQ/N) 


Debugging QTRM Application Programs 

8-36 


Supervisory Message Format, 


Turning Logging of Network Traffic 



All Connection Types 

3-13 

On/Off (QTDBG) 

8-38 

3-5 

Connection-Rejected (CON/REQ/A) 


Releasing Network Debug Log File (QTREL) 

8-38 


Supervisory Message Format, 


Flush AIP Debug Log File on Abnormal 



All Connection Types 

3-15 

Termination (QTSETF) 

8-39 

3-6 

Initialized-Connection (FC/INIT/R) 


Enter Message Into the Debug Log File . 



Supervisory Message Format 

3-15 

(QTLOG) 

8-39 

3-7 

Connection-Initialized (FC/INIT/N) 


Perform Binary Dump of Application 



Supervisory Message Format 

3-16 

(QTDMB) 

8-40 

3-8 

Connection-Broken (CON/CB/R) 


Turning Logging of AIP Statistics 



Supervisory Message Format 

3-17 

On/Off (QTSTC) 

8-40 

3-9 

End-Connection (CON/END/R) 


Enter Statistical Message Into the 



Supervisory Message Format 

3-18 

AIP Statistical File (QTLGS) 

8-40 

3-10 

Connection-Ended (CON/END/N) 


Sample Program 

8-41 


Supervisory Message Format 

3-iy 



3-11 

Application-to-Applicatlon Connection 





Supervisory Message Sequences 

3-20 



3-12 

Request-Application-Connection 


APPENDIXES 



(CON/ACRQ/R) Supervisory Message 





Format 

3-21 

A Character Data Input, Output, and 


3-13 

Application-Connection-Reject 


Central Memory Representation 

A-1 


(CON/ACRQ/A) Supervisory Message 


B Diagnostic Messages 

B-1 


Format 

3-24 

C Glossary 

C-1 

3-14 

Connection-Request (CON/KEQ/R) Super¬ 


D Application Program Call Statement 



visory Message Format, Appllcation- 


Summary 

D-1 


to-Appllcation Connections 

3-27 



3-15 

Connection Monitoring Message 





Sequences 

3-29 

INDEX 


3-16 

Inactive-Connection (FC/INACT/R) 





Supervisory Message Format 

3-30 



3-16.1 

. Set-Timer (DC/STMR/R) Supervisory 


FIGURES 



Message Format 

3-30.1 



3-17 

Connection Termination Message 


1-1 Overview of a GDC Network 

1-1 


Sequences 

3-30.2 

1-2 The Interfaces Between the Host and 


3-18 

Connection List Polling Control 


CCP Network Product Elements 

1-3 


Message Sequences 

3-32 

1-2#1 The Interfaces Between the Host and 


3-19 

Connection List Duplexing Message 


CDCNET Network Product Elements 

1-4 


Sequences 

3-32 

1-3 The Relationship Between the Parts of 


3-20 

Turn-List-Processlng-Off (LST/OFF/R) 


the Communications Control Program 

1-8 


Supervisory Message Format 

3-33 

1-4 Typical Connections in the Network 

1-10 





60499500 V 


xi 



3-21 Turn-List-Processing-On (LST/ON/R) 

Supervisory Message Format 3-33 

3-22 Change-Connection-List (LST/SWH/R) 

Supervisory Message Format 3-3A 

3-23 Turn-On-Half-Duplex-List-Processing 

(LST/HDX/R) Supervisory Message 
Format 3-34 

3-24 Turn-On-Ful1-Du piex-List-Processing 

(LST/FDX/R) Supervisory Message 
Format 3-35 

3-25 Block-Delivered (FC/ACK/R) Super¬ 
visory Message Format 3—36 ' 

3-26 Block-Not-Delivered (FC/NAK/R) 

Supervisory Message Format 3-37 

3-27 Appllcatlon-to-Application Connection 

Break and Reset Message Sequence 3-38 

3-28 Break (FC/BRK/R) Supervisory Message 

Format 3-38 

3-29 Reset (FC/RST/R) Supervisory Message 

Format 3-39 

3-30 Terminal User-Caused Break Sequence 3-39 

3-31 User-Interrupt (INTR/USR/R) Super¬ 
visory Message Format 3-40 

3-32 Break-Indication-Marker (BI/MARK/R) 

Supervisory Message Format 3-41 

3-33 Application-Interrupt-Response 

(INTR/RSP/R) Supervisory Message 
Format 3-41 

3-34 Resume-Output—Marker (RO/MARK/R) 

Supervisory Message Format 3-42 

3-35 Application-Interrupt (INTR/APP/R) 

Supervisory Message Format 3-43 

3-36 Application-Interrupt-Response 

(INTR/RSP/R) Supervisory Message 
Format 3-44 

3-37 Termlnate-Output-Marker (TO/MARK/R) 

Supervisory Message Format 3-44 

3-38 Device Connection Break and Reset 

Message Sequence 3-45 

3-39 Downline Data Flow Control Super¬ 
visory Message Sequences 3-45 

3-40 User-Interrupt-Request (INTR/USR/R) 

Supervisory Message Format for 
Priority Data 3-46 

3-41 User Interrupt for Priority Data 

Supervisory Message Sequence 3-46 

3-42 Change-Input-Character-Type 

Supervisory Message Sequence 3-47 

3-43 Change-Input-Character-Type 

(DC/CICT/R) Supervisory Message 
Format 3-48 

3-44 Block Truncation Supervisory Message 

Sequence 3-50 

3-45 Block Truncation (DC/TRU/R) Super¬ 
visory Message Format 3-51 

3-46 Device Characteristics Redefinition 

Supervisory Message Sequences 3—54 

3-47 Dev ic e-Char ac ter i s t Ic s-Rede f ined 

(TCH/TCHAR/R) Supervisory Message 
Format 3-55 

3-48 De f ine-Dev ic e-Char ac ter 1 sties 

(CTRL/DEF/R) Supervisory Message 
Format 3-56 

3-49 De f ine-Mul tipi e-Dev ic e-Char acteristics 

(CTRL/CHAR/R) Supervisory Message 
Format 3-57 

3-50 De fIne-Multipie-Devic e-Char ac ter1 sties 

Abnormal Response (CIRL/CHAR/A) 
Supervisory Message Format 3-58 

3-51 Mul tipi e-Device-Char acted St Ics- 

Defined (CTRL/CHAR/N) Supervisory 
Message Format 3-58 

3-52 Request-Device-Characteristics 

(CTRL/RTC/R) Supervisory Message 
Format 3-64 


3-53 Reque st-Dev ic e-Char ac te r is t ic s 

Abnormal Response (CTRL/RTC/A) 

Supervisory Message Format 3-b4 

3-54 Dev Ice-Characteristics-Definit ion 
(CTRL/TCD/R) Supervisory Message 
Format 3-65 

3-55 Define-CDCNET-Terminal-Char acteristics 
(CTRL/CTD/R) Supervisory Message 
Format 3-o6 

3-56 Define-CDCNET-Terminal-Char acteristics 
Abnormal Response (CTRL/CTD/A) 

Supervisory Message Format 3-67 

3-57 Define-CDCNET-Terminal-Char acteristics 
(CTRL/CTD/N) Supervisory Message 
Format 3-67 

3—57. 1 Request-CDCNET-Terminal- 

Characteristics (CTRL/RCC/R) 

Supervisory Message Format 3-68. 5 

3-57. 2 Request-CDCNET-Terminal- 

Characteristics Abnormal Response 
(CTRL/RCC/A) Supervisory Message 
Format 3-68.5 

3-57. 3 CDCNET-Terminal-Characterlstics- 
Definitions (CTRL/CCD/R) Super¬ 
visory Message Format 3—68.6 

3-58 Host Operator Command Supervisory 

Message Sequences 3—69 

3-59 Host Operator Request-to-Activate- 
Debug-Code (HOP/DB/R) Supervisory 
Message Format 3-70 

3-60 Host Operator Request-to-Turn-Off- 
Debug-Code (HOP/DE/R) Supervisory 
Message Format 3-70 

3-61 Host Operator Request-to-Dump-Fleld- 
Length (HOP/DU/R) Supervisory 
Message Format 3-/0 

3-62 Host Operator Request-to-Turn-AIP- 
Traffic-Logging-On (HOP/TRACE/R) 

Supervisory Message Format 3-71 

3-63 Host Operator Request-to-Turn-AIP- 
Trafflc-Loggiug-Off (HOP/NOTR/R) 
Supervisory Message Format 3—71 

3-64 Host Operator Request-to-Release- 

Debug-Log-File (HOP/REL/R) Super¬ 
visory Message Format 3-72 

3-65 Host Operator Re quest-to-Re star t- 
Statistics-Gatherlng (HOP/RS/R) 

Supervisory Message Format 3-72 

3—66 Host Operator Alert (HOP/ALT/R) 

Supervisory Message Format 3-73 

3-67 Host Operator Break (HOP/BRK/R) 

Supervisory Message Format 3-74 

3-68 Host Operator Command (HOP/CMD/R) 

Supervisory Message Format 3-74 

3-69 Host Dayfile (HOP/DAY/R) Supervisory 

Message Format 3-75 

3-70 Network Dayfile (HOP/LG/R) Super¬ 
visory Message Format 3-75 

3-71 Host Operator K-Dlsplay Data 

(HOP/DIS/R) Supervisory Message 
Format 3-76 

3-72 Host Operator End Display (HOP/END/R) 

Supervisory Message Format 3—76 

3-73 Host Operator Ignore (HOP/IG/R) 

Supervisory Message Format 3-7 7 

3-74 Host Operator Page (HOP/PAGE/R) 

Supervisory Message Format 3-77 

3-75 Host Operator START (HOP/START/R) 

Supervisory Message Format 3-78 

3-76 Host Shutdown Supervisory Message 

Sequences 3-78 

3-77 Host-Shutdown (SHUT/INSD/R) Super¬ 
visory Message Format 3-79 

3-78 Logical-Error Supervisory Message 

Sequence 3—79 


xii 


60499500 V 



3— 79 Logical-Error (ERR/LGL/R) Supervisory 

Message Format 

4- 1 NFETCH Macro Call Format 

4-2 NSTORE Macro Call Format 

4-3 NFETCH Integer Function FORTRAN 

Call Format 

4-4 NSTORE Subroutine FORTRAN Call Format 

4- 5 QTRM Interface Level Analogy 

5- 1 NETON Statement FORTRAN Call Format 

5-2 Supervisory Status Word Format 

5-3 NETON Statement FORTRAN Example 

5-4 NETOFF Statement FORTRAN Call Format 

5-5 NETGET Statement FORTRAN Call Format 

5-6 NETGET Statement FORTRAN 5 Examples 
5-7 NETGETF Statement FORTRAN Call Format 
5-8 NETGETF Statement Text Area Address 
Array 

5-9 NETGETF Statement FORTRAN 5 Examples 
5-10 NETPHT Statement FORTRAN Call Format 
5-11 NETPUT Statement FORTRAN 5 Example 
5-12 NETPUTF Statement FORTRAN Call Format 
5-13 NETPUTF Statement Text Area Address 
Array 

5-14 NETPUTF Statanent FORTRAN 5 Example 
5-15 NETGETL Statement FORTRAN Call Format 
5-16 NETGETL Statement FORTRAN 5 Example 
5-17 NETGTFL Statement FORTRAN Call Format 
5-18 NETGTFL Statement Text Area Address 
Array 

5-19 NETGTFL Statement FORTRAN 5 Example 
5-20 NETWAIT Statement FORTRAN Call Format 
5-21 NETWAIT Statement FORTRAN 5 Examples 
5-22 NETSETP Statement FORTRAN Call Format 
5-23 NETSETP and NETCHEK Statement 
FORTRAN 5 Examples 

5-24 NETCHEK Statement FORTRAN Call Format 

5- 25 NETFUNC Statement FORTRAN Call Format 

6- 1 Typical Job Structure for System 

Input 

6-2 Interactive Program Execution 
Procedure Example 

6-3 NETDBG Utility FORTRAN Call Statement 
Format 

6-4 NETREL Utility FORTRAN Call Statement 
Format 

6-5 NETSETF Utility FORTRAN Call Statement 
Format 

6-6 NETLOG Utility FORTRAN Call Statement 
Format 

6-7 NETDMB Utility FORTRAN Call Statement 
Format 

6-8 DLFP Command General Format 

6-9 DLFP Command Examples 

6-10 DLFP Directive Keyword Format 
6-11 DLFP Directive Examples 
6-12 General Format of DLFP Output 
6-13 NETSTC Utility FORTRAN Call Statement 
Format 

6-14 NETLGS Utility FORTRAN Call Statement 
Format 

6- 15 General Format of One Period Listing 

in Statistical File 

7- 1 Command Portion of RMV3 Job 

7-2 Program Portion of RMV3 



7-3 

Possible Dialogs Supported by Sample 


3-80 


FORTRAN Program 

7-25 

4-11 

7-4 

Debug Log File Listing tor Sample 


4-12 


FORTRAN Program 

7-26 


7-5 

Statistical File Listing for Sample 


4-13 


FORTRAN Program 

7-38 

4-13 

8-1 

Network Information Table Format 

8-2 

4-15 

8-2 

QTOPEN Statement COBOL Cali Format 

8-26 

5-2 

8-3 

QTCMD Statement COBOL Cali Format 

8-27 

5-3 

8-4 

QTPUT Statement COBOL Call Format 

8-29 

5-3 

8-5 

QTGET Statement COBOL Call Format 

8-30 

5-4 

8-6 

QTLINK Statement COBOL Call Format 

8-32 

5-4 

8-7 

QTENDT Statement COBOL Call Format 

8-32 

5-5 

8-8 

QTLEND Statement COBOL Call Format 

8-33 

5-6 

8-9 

QTSUP Statement COBOL Call Format 

8-34 


8-10 

QTCLOSE Statement COBOL Call Format 

8-34,3 

5-7 

8-11 

Algorithm for Output Buffering 


5-7 


Using QTRM 

8-37 

5-8 

8-12 

QTDBG Statement COBOL Call Format 

8-38 

5-8 

8-13 

QTREL Statement COBOL Call Format 

8-3 9 

5-9 

8-14 

QTSETF Statement COBOL Call Format 

8-39 


8-15 

QTLOG Statement COBOL Cali Format 

8-40 

5-9 

8-16 

QTDMB Statement COBOL Cali Format 

8-40 

5-10 

8-17 

QTSTC Statement COBOL Call Format 

8-41 

5-11 

8-18 

QTLGS Statement COBOL Cali Format 

8-41 

5-12 

8-19 

Sample Program ECH0-RMV2 Source 


5-12 


Listing 

8-42 


8-20 

ECH0-RMV2 Job Commands 

8-55 

5-13 

8-21 

Debug Log File Listing for ECH0-RMV2 

8-56 

5-14 

8-22 

Statistics File Listing for ECHO-RMV-2 

8-65 

5-14 

8-23 

ECHO—RMV2 Sample Dialog 

8-06 

5-15 




5-15 




5-16 




5-17 

TABLES 


5-17 





1-1 

Device Types 

1-9 

5-2 

1-2 

Supported Terminal Classes 

1-14 


2-1 

Default Message Delimiter and 


6-3 


Transmission Keys 

2-0 


2-2 

CCP Format Effector Operations for 


6-7 


Asynchronous and X. 25 Consoles 

2-15 


2-3 

CCP Format Effector Operations for 


6-8 


Synchronous Consoles 

2-20 


2-4 

Embedded Format Control Operations 


6-8 


for Consoles 

2-21 


2-5 

Character Exchanges With Connections 

2-26 

6-9 

3-1 

Legal Supervisory Messages 

3-1 


3-2 

Valid CCP Field Numbers and Field 


6-9 


Val ue s 

3-59 

6-10 

3-3 

CDCNET Attribute Changes Associated 


6-10 


With All Terminal Class Changes 

3-63 

6-11 

3-4 

CDCNET Attribute Setting Changes 


5-12 


Associated With Specified 


6-13 


Terminal Classes 

3-63 


3-5 

Valid CDCNET Attribute Numbers and 


6-15 


Attribute Values for Asynchronous 




Terminals 

3-08 

6-15 

3-b 

CCP Field Number to CDCNET Attribute 




Number Mapping 

3-68. 2 

6-16 

4-1 

Reserved Symbols 

4-3 

7-1 

4-2 

AIP Internal Procedures 

4-18 

7-2 

4-3 

AIP Internal Tables and Blocks 

4-19 


60499500 V 


xiil/xlv 




NOTATIONS 


Throughout this manual, the following conventions 
are used In the presentation of statement formats, 
operator type-ins, and diagnostic messages: 

UPPERCASE Uppercase letters Indicate 

acronyms, words, or mne¬ 
monics either required by 
the network software as 
input, or produced as out¬ 
put. 

lowercase Lowercase letters identify 

variables for which values 
are supplied by the NAM or 
terminal user, or by the 
network software as output. 

... Ellipsis indicates that 

omitted entities repeat the 
form and function of the 
entity last given. 

[ ] Square brackets enclose 

entities that are optional; 
if omission of any entity 
causes the use of a default 
entity, the default is 
underlined. 

{ } Braces enclose entities from 

which one must be chosen. 

input parameter This term identifies an AIP 

call statement parameter for 
which values are supplied 
to AIP by the programmer. 

return parameter This term identifies an AIP 
call statement parameter 
for which variables are 
supplied to AIP by the pro¬ 
grammer and in which values 
are placed by AIP. 


<ct> The <ct> symbol represents 

the network control char¬ 
acter defined for the ter¬ 
minal. This character must 
be the first character of 
the command ente red. 


LF The LF symbol represents a 

one-line vertical reposi¬ 
tioning of the cursor or 
output mechanism. LF also 
designates a character or 
character code associated 
with such a line feed 
operation. 

A circle around a character 
represents a character key 
that is pressed in con¬ 
junction with a control 
key (CTL, CNTRL, CONTRL, 
CONTROL, or equivalent). 

|cr I The boxed cr symbol repre¬ 

sents the terminal key that 
causes message transmission; 
usually, this key causes a 
carriage return operation. 
Transmission keys are 
described in more detail in 
section 2. 


Unless otherwise specified, all references to num¬ 
bers are to decimal values, all references to bytes 
are to 8-blt bytes, and all references to characters 
are to 7-blt ASCII-coded characters. Fields 
defined as unused should not be assumed to contain 
zeros. 
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NETWORK PRODUCTS: AN OVERVIEW 


1 


This section introduces the Control Data Corporation 
CYBER 170 network products, their relationships to 
each other, and their significance to the data com¬ 
munications user. Network products is a group of 
programs and hardware that provides communications 
services to geographically dispersed users. 

As shown in figure 1-1, a CDC network consists of a 
computer network, a communications network, and a 
services network. 


COMPUTER NETWORK 

The computer network includes host computer systems 
packet-switching networks (PSNs), terminals, and 
the host software associated with network communi¬ 
cations . 

Each component of the computer network provides 
input, output, control, or storage resources to the 
services and communications network. The primary 
host communication software is called the Network 
Access Method (NAM). 
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COMMUNICATIONS NETWORK 

The communications network includes network proc¬ 
essing units (NPUs) and the connecting communication 
lines needed to transport blocks of data between 
host computers and terminals. The primary CDC 
software in an NPU is called the Communications 
Control Program (CCP). 

The size and complexity of a communications network 
varies from a simple network with one local (front- 
end) NPU, or a network with one local NPU and one 
or more remote NPUs, to a more complex network with 
multiple local NPUs and multiple remote NPUs. 
Attached to these NPUs are terminal devices, such 
as entry/display stations. 

Because the communications network minimizes termi¬ 
nal type dependency and removes many of the terminal 
switching operations from the host, the host can 
process data more efficiently. 


SERVICES NETWORK 

The services network consists of the network appli¬ 
cation programs in each host computer and the users 
of those programs. Each application program gives 
the terminal user or another application a specific 
data processing capability. 


SOFTWARE COMPONENTS OF 
THE NETWORK 

Figures 1-2 and 1-2.1 show the interfaces between 
the elements of the network. The left part of each 
figure shows the network host software elements, 
which are the software elements located in the CDC 
CYBER 170 host computer. 

The middle section of figure 1-2 shows the Com¬ 
munications Control Program (CCP), which is the 
software element located in the network processing 
unit. As shown in the right portion, CCP commun¬ 
icates with the terminals while the Network Access 
Method (NAM) communicates with application programs. 

The network host software is collectively called 
the Network Access Method or NAM. NAM is used in 
several contexts throughout this manual and in the 
other network products documentation. NAM can refer 
to the Interface between application programs and 
the communications network; to the programs that 
implement that Interface, including the Applications 
Interface Program (AIP), the Network Interface 
Program (NIP), and the Peripheral Interface Program 
(PIP); or to the product NAM, which also Includes 
the Network Supervisor (NS), the Communications 
Supervisor (CS), and the Network Validation Facility 
(NVF). 

In figures 1-2 and 1-2.1, NAM refers to the set of 
programs that Implement the interface between the 
application programs and communications network. 

Network host software, shown in the left part of 
figure 1-2, includes: 

Network Access Method 

Network Definition Language Processor 


Network Supervisor (CCP networks only) 
Communications Supervisor 
Network Validation Facility 
Network utilities 

Network Access Method application programs 

CYBER Cross System (CCP networks only) 

CDCNET network software, shown in the left part of 
figure 1-2.1, includes: 

Network Access Method 

Network Definition Language Processor 

Network Validation Facility 

Network Access Method Utilities 

Network Utilities 


NETWORK ACCESS METHOD 

The Network Access Method is the primary network 
host software. NAM interfaces between applications 
in the same host or between applications and the 
Communications Control Program in an NPU or CDCNET 
Device Interfaces (DIs), 

Because the connections among NPUs or DIs can be¬ 
come extremely complex, the Network Access Method 
acts as an interface between host computer software 
at one end of the network and the terminals at the 
other end. 

A simple front-end configuration appears the same 
through the Network Access Method as a more complex 
linkage system; message routing by Che host com¬ 
puter is performed in the same manner for both 
configurations. The physical and logical configu¬ 
ration of the elements involved in Network Access 
Method operation is described in the Network Defi¬ 
nition Language reference manual (listed in the 
preface). 

The host computer executes CDC-written or site- 
written service programs called application programs 
that are connected to the network via the Network 
Access Method (NAM). An application program can 
communicate with other application programs or 
service terminals connected to the network. All 
connections to the network are established by a 
portion of the network software called the Network 
Validation Facility, and the flow of data and proc¬ 
essing along them is controlled through NAM. 

NAM incorporates the following features: 

• It is equally suitable for application programs 
written in COMPASS or high-level languages, such 
as FORTRAN. 

• It imposes no data structures on an application 
program. 

• It provides a way to handle unpredictable 
events, such as terminal operator interrupts. 

• It provides complete isolation of network com¬ 
munications from the operating system. 
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Figure 1-2. The Interfaces Between the Host and CCP Network Product Elements 
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Figure 1-2.1. The Interfaces Between the Host and COCNET Network Product Elements 













• It ‘supports distinct classes of terminals by 
normalizing data formats and optionally per¬ 
forming code conversion. Eighteen classes are 
defined by GDC; additional classes can be de¬ 
fined by sites that provide their own supporting 
software. 

• It permits an application program to support 
clusters of real terminal devices as Lf the 
devices were separately addressable logical 
entities called virtual terminals. Virtual 
terminals are described at the end of this 
section. 

Basic services provided by NAM include: 

• NAM establishes massage paths (logical con¬ 
nections) between an application program and 
terminals or between two applications (provided 
both parties have the correct network access 
security permissions). 

• NAM breaks logical connections when asked to by 
the application program or the terminal, or when 
network conditions make it necessary (for ex¬ 
ample, when a network shutdown occurs). 

• After logical connections have been established, 
NAM passes Incoming messages to the application, 
and accepts and forwards outgoing messages from 
the application. 

• NAM queues incoming messages until the appli¬ 

cation program requests them. This allows the 
application to service its connections with 
terminals and other applications in any desired 
order. 

• NAM provides the application program with its 

own set of protocols, making knowledge of de¬ 

tailed network protocols unnecessary. 

• For incoming traffic, NAM allows the application 
program to group terminals with similar or re¬ 
lated processing needs. 

• NAM queues outgoing messages to regulate data 

flow through the network. 

• NAM detects inactivity on any interactive data 
path and reports the condition to the appli¬ 
cation program. 

• NAM resolves resource contention among appli¬ 

cation programs. 

An installation option is available to log message 

traffic for application program debugging. A second 

installation option permits the logging of appli¬ 
cation program and message traffic statistics. 


NAM consists of four major modules: 
Peripheral Interface Program 
Network Interface Program 
Application Interface Program 
Queued Terminal Record Manager 


Peripheral Interface Program 

The Peripheral Interface Program (PIP) is a periph¬ 
eral processor unit program that interfaces the 
central processor executed routines of NAM to the 
channel-connected local NPUs or CDCNET Mainframe 
Device Interfaces. 

PIP moves blocks of data between the central memory 
buffers of NAM and the NPU or DI and reads and 
writes disk files used by batch devices or for file 
transfer. PIP also can detect when a local NPU 
needs initializing. If the NPU cannot start its 
own loading, PIP requests the network supervisor to 
load the bootstrap program into the NPU. 


Network Interface Program 

The Network Interface Program (NIP) executes as a 
system control point. NIP coordinates the use of 
the communications network by all application pro¬ 
grams, buffers data between the application programs 
and the network, and manages the logical connec¬ 
tions. 

Each application program can have several connec¬ 
tions; each connection is associated with a terminal 
device or with another application program. NIP 
translates between network addresses and the more 
convenient logical addresses that represent the 
connection to the application. NIP also establishes 
new connections as they are requested and terminates 
connections that are no longer needed or that have 
failed. 

An application can request NAM to convert the data 
on a logical connection from the network format. 
Such conversions determine the format and encoding 
of characters seen by, the application. 

Application Interface Program 

The Application Interface Program (AIP) is a set of 
subprograms and buffers that resides in the appli¬ 
cation program's field length and provides an 
interface to NIP and the network. This manual is 
primarily concerned with the use of AIP. 

AIP statements are provided so that the application 
program can connect to and disconnect from the net¬ 
work, AIP statements also control information 
exchange between the application program and NAM 
buffers. This information can be data, or it can 
be supervisory messages that coordinate the appli¬ 
cation's execution with events that have occurred 
in the network. NAM might pass a supervisory mes¬ 
sage to inform the application of a new connection 
that is requesting service, or that a failure has 
occurred. In the same way, the application program 
uses supervisory messages to communicate with NAM 
and the network elements. 


Queued Terminal Record Manager 

The Queued Terminal Record Manager (QTRM) is a set 
of subprograms that resides in the application pro¬ 
gram's field length and provides a high level pro¬ 
cedural interface to the network. This package 
permits indirect use of a subset of AIP's features 
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NETWORK VAIIDATION FACILITY 


by programs with unsophisticated communications 
requirements. This utility permits programs to 
have a communications interface functionally similar 
to their mass storage interface. QTRM is discussed 
in section 8 of this book. 


NETWORK DEFINITION LANGUAGE 
PROCESSOR 

Before the network software can route data through 
the network and interface to operators for super¬ 
vision, the definition of the network configuation 
must first be communicated to the software. The 
Network Definition Language (NDL) is used to de¬ 
scribe this configuration. The Network Definition 
Language processor (NDLP), a batch utility, trans¬ 
lates this configuration and prepares a network 
configuration file (NCF) and a local configuration 
file (LCF). 

The NCF contains configuration information required 
by the network. 

The LCF contains host information required by the 
Network Validation Facility, such as automatic login 
parameters and application information. The LCF 
allows the network validation facility to validate 
and connect terminals to applications or appli¬ 
cations to applications. 

The NDL Is described in the Network Definition 
Language reference manual listed in the preface. 


NETWORK SUPERVISOR 

The Network Supervisor (NS) executes as a NAM 
application. It interfaces between the NPUs and 
CCP program files in the host. NS loads an NPU on 
request with the appropriate copy of the Communi¬ 
cations Control Program from the host's network 
load file (NLF). NS also saves NPU dumps in the 
host's network dump file (NDF). The load and dump 
files are shown in figure 1-2. 

The host operator can obtain status information for 
NPU loading or dumping operations involving the 
copy of NS in the operator's host. More than one 
host can run a copy of NS; so that NS can load NPUs 
which are not accessible from a specific host. 


COMMUNICATION SUPERVISOR 

The Communication Supervisor (CS) program,executes 
as a NAM application. It can communicate with the 
network operators (NOP). CS allows a network 
operator at a terminal (an NPU operator or a diag¬ 
nostic operator [DOP]) or at a host console (a host 
operator [HOP]) to obtain and change the status of 
network elements under its supervision, to communi¬ 
cate with users at terminals, and to run diagnos¬ 
tics. CS also responds to requests for network 
configuration data from an NPU. 

CS can run in one or more hosts. It also assists 
the NPUs by providing them with terminal configura¬ 
tion information from the network configuration 
file. 


The Network Validation Facility (NVF) also executes 
as a NAM application. It validates the terminal 
user's access to the host and an application pro¬ 
gram's access to the computer network. NVF also 
maintains and reports application status to the 
host operator (HOP). As figure 1-2 shows, the NOS 
validation file and the local configuration file 
(LCF) supply validation Information to NVF. 

NVF verifies such terminal user information as 
family name, user name, and password. Before a 
terminal user can access an application program, 
successful login must occur. When login is 
successfully completed, the Network Validation 
Facility causes NAM to notify the application 
program identified in the login sequence that a 
terminal requests connection. 

The Network Validation Facility also performs 
switching between application programs. NVF causes 
terminal disconnection processing when disconnection 
is appropriate. 

The Network Validation Facility controls application 
program and terminal access to the network, as 
follows: 

. An application program wishing to communicate 
with terminals requests access to the network. 

This request is passed by NAM to the NVF for 

validation. (NVF also performs similar vali¬ 
dation of terminal requests for host access.) 
Once NVF has determined that an application 

program or terminal is allowed to use the host's 
resources, it makes calls to NAM that create 
the logical connection for the transfer of data 
between the application program and the network. 
NVF also requests NAM to modify or delete these 
connections when terminal users request to com¬ 
municate with other application programs or 
leave the network. 

• When an application program no longer desires 

to use the network, it calls another NAM pro¬ 
cedure. This request also is passed to NVF, 
which causes NAM to delete all connections used 
for the application program - just as it does 
for a terminal or terminal device leaving the 
network, 

NETWORK UTILITIES 

Four utility programs either are included with or 
used by network host products: 

The Network Dump Analyzer (NDA) 

The Load File Generator (LFG) 

The Debug Log File Processor (DLFP) 

The Hardware Performance Analyzer (HPA) 


Network Dump Analyzer 

The network dump analyzer (NDA) produces a formatted 
printout from NPU dump files created by the Network 
Supervisor. The site analyst can use these dumps 


1-6 


60499500 U 



to help analyze CCP software or NPU hardware fail¬ 
ures. The network dump analyzer uses the network 
dump file (NDF), which is shown in figure 1-2, as 
input. 

You can find more information about the network 

dump analyzer in the NOS Version 2 Analysis 

Handbook listed in the preface. 

Load File Generator 

The load file generator (LFG) reformats CCP program 
files produced by the CDC CYBER Cross System's link 
and edit programs into a single random access file 
used by the Network Supervisor to load NPUs. This 

file is the network load file (NLF), which is one 

of the NPO files shown in figure 1-2. 

You can find more information about the load file 
generator in the NOS Installation Handbook listed 
in the preface. 


Debug Log File Processor 

The debug log file processor (DLFP) converts the 
debug log file generated by the Application Inter¬ 
face Program into a printable report. The program¬ 
mer can selectively list logged information through 
DLFP directives. 

You can find more information about the debug log 
file processor in section 6 of this manual. 


Hardware Performance Analyzer 

A fourth utility program, the hardware performance 
analyzer (HPA), is part of the NOS operating system. 
This utility program produces reports from infor¬ 
mation on the account and error log dayflles. 
Network products software makes statistical, error, 
and alarm message entries into these dayfiles. 

You can find more Information about the hardware 
performance analyzer in the HPA reference manual 
listed in the preface. 


NAM APPLICATION PROGRAMS 

The host computer executes CDC-written or site- 
written service programs called application programs 
that are connected to the network through NAM. An 
application program can communicate with other 
application programs or terminals connected to the 
network. 

The CDC-provlded NAM application programs are: 

Interactive Facility (lAF), which allows you to 
create files and to create or execute programs 
from a device without using card readers or line 
printers. lAF is described in Volumes 1 and 3 
of the NOS 2 Reference Set. 

Remote Batch Facility (RBF), which permits you 
to enter a job file from a remote card reader 
and to receive job output at a remote batch 
device. RBF is described in the Remote Batch 
Facility reference manual. 


Transaction Facility (TAF), which permits you 
to implement on-line transaction processing 
under NOS by writing programs to be used by 
terminals. TAF is described in the TAF 
reference manual. 

Terminal Verification Facility (TVF), which 
provides tests you can use to verify that an 
interactive console is sending and receiving 
data correctly. TVF is discussed in the Ter¬ 
minal Interfaces reference manual. 

Message Control System (MCS), which allows you 
to queue, route, and journal messages between 
COBOL programs and terminals. MCS is described 
in the Message Control System reference manual. 

Queue File Transfer Facility (QTF), which 
allows you to transfer queue files between 
hosts. The use of this feature is described in 
the NOS Version 2 Reference Set, Volume 3, 

Permanent File Transfer Facility (PTF), which 
allows you to transfer permanent files between 
waits. The use of this feature is *^documented 
in the NOS Version 2 Reference Set, Volume 3. 

Printer Support Utility (PSU), which provides 
you with the ability to print NOS queue files 
on a Centronics Linewriter 400 or 600 printer 
using asynchronous connections to the network. 
Volume 3 of the NOS Reference Set describes how 
users route files to such printers. The NOS 
Operations Handbook describes how operators 
maintain and monitor such printers. 

NOS/VE Interactive Facility (VEIAF), which 
allows you to create files and execute Jobs on 
NOS/VE. All of the NOS/VE ' manuals comprise 
VEIAF documentation. 

Interactive Transfer Facility (ITF), which 
allows you to connect to the CYBER 200 computer 
systems. ITF is described in the VSOS 
documentation. 


CDC CYBER CROSS SYSTEM SOFTWARE 

The CDC CYBER Cross System software allows you to 
Install, modify, and maintain the CCP software. It 
is composed of these programs: 

PASCAL, which is a compiler patterned after 
ALGOL-60, By using PASCAL, you can define tasks 
in statements that are processed by the compiler 
to yield a variable number of actual program 
instructions. 

Formatter, which reformats PASCAL output into 
an object code format compatible with the com¬ 
munications processor macro assembler output 

Macro Assembler, which assembles communications 
processor macro memory source programs and 
produces relocatable binary output. The source 
programs are written with symbolic machine, 
pseudo, and macro instructions. 

Micro Assembler, which provides the language 
needed to write a micro memory program. This 
assembler translates symbolic source program 
instructions into object machine instructions. 


60499500 V 


1-7 



Link Editor, which accepts object program mod¬ 
ules and generates a memory image, suitable for 
executing in the 255x NPU. 

Autolink utility, which simplifies program 
assignment and maximizes the amount of space 
assigned to handling buffers. 

Expand utility, which includes several hardware 
and software variables used to define a CCP load 
file for a given NPU configuration. 

See the preface for manuals that contain more 
information on the CDC CYBER Cross System. 


NETWORK PROCESSING UNIT 
AND COMMUNICATIONS 
CONTROL PROGRAM 

This subsection discusses the following network 
products, which are part of the communications 
network and allow a terminal to access the host 
computer over communication lines: 

The 255x series network processing unit (NPU), 
which connects a host to a terminal 


The Communications Control Program (CCP), which 
is the software in the NPU 


The middle portion of figure 1-2 shows the communi¬ 
cations network. 


NETWORK PROCESSING UNIT 

An NPU handles front-end or remote data communica¬ 
tions for the CDC CYBER 170 host. The Communica¬ 
tions Control Program resides within the NPU. 

To understand CCP, you must have a basic under¬ 
standing of the hardware on which CCP runs. Refer 
to the hardware manuals listed in the preface for a 
description of the hardware components of the NPU. 

COMMUNICATIONS CONTROL PROGRAM 

The Communications Control Program, which is the 
software that executes in the 255x NPUs, consists 
of: 

Base system software 

System autostart module program (SAM-P) 

Service module (SVM) 

Host Interface Program (HIP) 

Terminal Interface Programs (TIPs) 

Link Interface Program (LIP) 

Block Interface Program (BIP) 

In-line and on-line diagnostics 

NPU console debugging aids 

Performance and statistics programs 

Figure 1-3 shows how the major parts of CCP relate 
to each other. 



Figure 1-3. The Relationship Between the Parts of the Communications Control Program 


1-8 


60499500 V 










Base System Software 

The base system software executes programs, allo¬ 
cates buffers, handles interrupts, and supports 
timing and data structures. It includes: 

A system monitor, which controls the allocation 
of resources for the communications processor 

Timing services, which run those programs or 
functions that are executed either periodically 
or following a specific time lapse for the 
processor 

A multiplex subsystem, which interfaces with 
the 255x multiplexing hardware and performs 
character-by-character processing of tasks 

Interrupt handler, which controls the transi¬ 
tion of the communications processor between 
different program interrupt levels 

Initialization, which prepares the network for 
on-line operation 

Structure services, which build and maintain 
internal tables used for routing data 

Buffer maintenance, which dynamically allocates 
memory in multiple buffer sizes for efficient 
memory use 

Worklist services, which provide logic for 255x 
Interprogram communication through the use of 
workllsts 

Standard subroutines, which provide support 
routines to handle arithmetic conversion, main¬ 
tain page registers, and do miscellaneous tasks 


System Autostart Module 

The system autostart module is an . optional set of 
hardware and software that begins the loading of 
other CCP software from a host. 


Service' Module 

The service module (SVM) includes network control 
functions and interface programs that provide a 
common link to other elements of the communications 
network. These programs: 

Process commands from the host, called service 
messages 

Control line and terminal configuration 

Report and respond to regulation and supervision 
changes 


Host Interface Program 

The Host Interface Program (HIP) provides the soft¬ 
ware that links the host and a local NPU over a 
channel. The HIP drives the CDC CYBER channel 
coupler, transfers data, checks for errors, and 
monitors for host failure and recovery. 


Terminal Interface Program 

The Terminal Interface Program (TIP) is a modular 
program that provides protocol support and the con¬ 
trol needed to interchange data between a terminal 
and other elements of CCP. 

The TIP transforms application program data between 
its virtual terminal format and the format required 
by the transmission protocol and physical charac¬ 
teristics of the real terminals. CDC provides TIPs 
for these transmission protocols: 

• Asynchronous communication lines 

• Synchronous communication lines for mode 4 
terminals 

• Bisynchronous communication lines for terminals 
emulating the IBM HASP protocol 

• X.25 packet and link level interfaces to a 
packet-switching network (PSN) via high-level 
data link control (HDLC) synchronous lines 

• Bisynchronous communications lines for terminals 
emulating the IBM 2780/3780 protocol 

• 3270 Bisynchronous communications (BSC) oper¬ 
ating as multipoint data links 

Eighteen classes of real terminals using these 
protocols are supported. Each terminal class has 
certain physical characteristics associated with 
it. These associated characteristics are determined 
by a terminal chosen as the archetype for the class, 
but can be changed by either the application pro¬ 
gram or the terminal operator. The terminal class 
initially used for a given real terminal is deter¬ 
mined by the way the terminal is configured in the 
network configuration file; the network configura¬ 
tion file can also be used to change the character¬ 
istics initially associated with the terminal from 
those of the archetype terminal. The association 
of characteristics with a terminal is referred to 
in networks documentation as terminal definition or 
TERMDEF. 

The terminal classes and archetype terminals for 
each class are listed at the end of this section. 

This list includes only elements supported by re¬ 
leased versions of standard CDC network software. 

Sites can add site-written Terminal Interface Pro¬ 
grams to extend CDC support to additional transmis¬ 
sion protocols and terminal classes. This manual 
is concerned only with the transmission protocols 
and terminal classes supported by CDC. Information 
in this manual is valid for sites using extensions 
to CCP only to the extent that those modifications 
emulate the CDC-supported release version of CCP. 

Link Interface Program 

The Link Interface Program (LIP) transfers infor¬ 
mation over a trunk between NPUs. 


Block Interface Program 

The Block Interface Program (BIP) routes blocks of 
data, processes service messages, and processes the 
network block protocol. 
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In-Line and On-Line Diagnostics 

In-line and on-line diagnostics, which are produced 
for the NPU, enable a NOP to isolate conraiunications 
line problems. Alarm, CE error, and statistics 
service messages are the types of in-line diag¬ 
nostics. In-line diagnostics are generated auto¬ 
matically. On-line diagnostics must be requested 
from the NOP console. 


NPU Console Debugging Aids 

Debug aids provide test utilities for debugging 
programs, taking memory snapshots, and dumping the 
NPU during CCP program development or system 
failures. 


Performance and StafisHcs Programs 

These programs gather statistics on NPU and indi¬ 
vidual line performance, and periodically dispatch 
these statistics to the Communications Supervisor. 

DEVICE INTERFACES AND CDCNET 

Small communications processors called device 
Interfaces (DIs) constitute the hardware portion of 
CDCNET. 

The CDCNET network software consists of the 
following components: 

Base system software 

Layer sof tware 

Interface software and gateways 
Network management software 

BASE SYSTEM SOFTWARE 

The base system software performs two major tasks: 

Initialises the operation of the device 
interface (DI) 

Maintains the operational environment of the DI 
by serving as its executive routine, by 
detecting and reporting DI malfunctions, and by 
managing the DI's onboard diagnostics 

You can find more Information on the CDCNET base 
system software in the CDCNET Systems Programmer's 
Reference Manual, Volume 1, Base System Software. 


LAYER SOFTWARE 

CDCNET layer software enables applications 
software, end users, terminals or workstations, and 
host computers to exchange information through a 
compatible set of protocols and Interfaces. 


You can find more information on the CDCNET layer 
software by in the CDCNET Systems Programmer's 
Reference Manual, Volume 2, Network Management 
Entities and Layer Interfaces. 


INTERFACE SOFTWARE AND GATEWAYS 

CDCNET interface software and gateways consist of 
various software packages that enable CDCNET DIs 
and hosts that accomodate. Control Data Network 
Architecture (CDNA) to communicate with other 
hosts, networks, and terminals/workstations which 
do not support CDNA, 

You can find more information on the CDCNET 
interface software and gateways in Volume 2, 
Network Management Entities and Layer Interfaces 
and Volume 3, Network Protocols of the CDCNET 
Systems Programmer's Reference Manual. 


NETWORK MANAGEMENT SOFTWARE 

CDCNET network management software performs daily 
and periodic tasks related to the administration, 
maintenance, and operation of the communications 
network. 

You can find more information on the CDCNET network 
management software in the CDCNET Systems 
Programmer's Reference Manual, Volume ,2, Network 
Management Entitles and Layer Interfaces. 


DEVICE INTERFACES 

Each DI supporting terminal connections contains a 
Terminal Interface Program that performs functions 
similar to those of a CCP TIP. CDCNET TIPs do not 
use the terminal class concept. 

Because CDCNET distributes major communications 
functions throughout a network, DIs perform 
different functions depending on their particular 
network task: 

Mainframe DI (MDI) that lets you connect a host 
CYBER computer system to a local area network. 

Terminal DI (TDI) that lets you connect user 
terminals and workstations to a local area 
network. 

Network DI (NDI) that lets you connect one 
CDCNET local area network to other networks. 

CDC also offers a mainframe/terminal DI (MTI) that 
lets you connect user terminals/workstations to a 
CYBER host without requiring that they be tied into 
a local area network. 

You can find further information on CDCNET network 
device interfaces in the CDCNET Reference Manual. 


1 - 8.2 


60499500 U 



THE PACKET SWITCHING 
NETWORK (PSN) 

The packet switching network (PSN) is a value added 
network you may subscribe to either from a CDC or a 
foreign vendor who supports the X. 25 CCITT recom¬ 
mendation (1980). Such networks are alternately 
referred to as public data networks (PDNs). 


NAM CONCEPTS 

NAM is used by both application programs and por¬ 
tions of the network software. The features of NAM 
permit programs to be written for the following 
types of communication applications; 

• Time-sharing communication services. A single 
program provides this service when it interacts 
with each terminal during a given time period. 
The CDC-wrltten Interactive Facility is an 
example of this type of application program. 

• Transaction communication services. A single 
program provides this service when it creates a 
multi-threading Interface for many terminals 
using many task routines. Each terminal can 
interact with many tasks or programs through 
queues maintained by the program providing the 
transaction service. The CDC-written Trans¬ 
action Facility is an example of this type of 
application program. 

• Teleprocessing communication services. A 
single program provides this service when it 
Interacts with many terminals to perform a 
single teleprocessing task for each. No task 
queues are required. The CDC-written Terminal 
Verification Facility is an example of this 
type of application program. 


VIRTUAL TERMINALS 

The virtual terminal concept simplifies the proce¬ 
dure an application program must perform to service 
a terminal. 

Device types are used in a request for connection 
from a terminal to an application (see section 3 
for a discussion of connection processing). Device 
types currently defined are listed in table 1-1. 

Every terminal device is either an Interactive 
device (capable of both input and output) or a 
batch device (capable of either input or output). 
Because this is true of all physical terminals, 
certain functions of each terminal device type can 
be abstracted and treated in a similar manner for 
all terminals with devices of that type. These 
common functions constitute a virtual terminal. 
All references to terminals in this manual are to 
virtual terminals, unless otherwise specified. 

The interactive virtual terminal concept makes it 
unnecessary for an application programmer to provide 
separate procedures to support differing implemen¬ 
tations of one function on a variety of real ter¬ 
minals . 

Any console or site-defined device (any device with 
a device type of 0 or 12) can be serviced as an 
interactive virtual terminal. An interactive 
virtual terminal has an input and output device 


TABLE 1-1. DEVICE TYPES 


Device Type 

Terminal Device Defined 

0 

Console (interactive device) 

it 

Card reader (passive device) 

2t 

Line printer, impact printer 
or nonimpact printer (passive 
device) 


Card punch (passive device) 

4t 

Plotter (passive device) 

5 

Another application program in 
the same host 

6 

Another application program in 
a different host 

7 thru 11 

Reserved for CDC use 

12 

Site-defined device 

tReserved for 

RBF use. 


which sends and receives logical lines of ASCII 
characters. These logical lines are transformed 
into or from physical lines of characters of the 
code set appropriate for the real terminal. This 
transformation is performed for the application 
program by the Communications Control Program of 
the network processing unit servicing the real 
terminal. 

Real terminals can perform a wide variety of 
functions, but not all terminals can perform the 
same functions. The functions performed by an 
interactive virtual terminal are restricted to the 
subset of terminal functions that is common to all 
real interactive terminals. This restriction 
ensures efficient virtual terminal operation when 
the corresponding real terminal has the fewest 
capabilities. 

When the application program must support functions 
for a real terminal that are not available through 
the interactive virtual terminal interface, the 
application program can: 

• Embed control characters in the output text or 
scan for control characters in the input text. 
The application program must allow for control 
characters significant to or transformed by the 
network software in this instance. 

• Transfer data to and from the terminal in 
transparent mode. In transparent mode, all 
transformations are inhibited and the appli¬ 
cation program has direct access to and re¬ 
sponsibility for support of all real terminal 
functions. Transparent mode can be selected 
separately for input and output to the same 
virtual terminal. 

Control characters and transparent mode are discus¬ 
sed in detail in section 2. 
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Logical lines that exceed the physical line length 
of the real terminal are folded into two or more 
physical lines on output to the terminal. The 
spacing of output lines can also be controlled with 
optional format effectors, described in section 2. 
Optional paging of output is possible, to avoid 
overwriting previous output until the previous out¬ 
put is acknowledged by the terminal operator. 

LOGICAL CONNECTIONS 

Just as the virtual terminal concept simplifies 
terminal servicing, the logical connection concept 
simplifies terminal addressing. In the network, 
when data passes between a virtual terminal and an 
application program, a message path or logical con¬ 
nection exists between the two. Conceptually, this 
is equivalent Co the connection between two tele¬ 
phones used in a conversation. After a real termi¬ 
nal has gained network access, NAM logically con¬ 
nects each virtual terminal portion of it to one, 
and only one, application program at a time, al¬ 
though the virtual terminal can be switched from 
application to application as needed. 

An application program, however, can be connected 
simultaneously to many virtual terminals. It Is 
connected to each one by a separate and distinct 
logical connection. The application program 


identifies a particular terminal by specifying the 
logical connection between Itself and the terminal. 
This is possible because a one-to-one association 
exists between the connection and the terminal. 
From the application programmer's point of view, it 
is convenient to talk of connection x (literally, 
message path x) when it would be more precise to 
say the virtual terminal at the other end of con¬ 
nection X. 

An application program can also form a logical 
connection with one or more other applications and, 
in fact, can have several connections with another 
application program simultaneously, using separate 
and distinct logical connections. A logical con¬ 
nection can, therefore, refer to either a terminal 
or to another application. This manual uses the 
term connection to cover both possibilities. 
Typical logical connections in the network are shown 
in figure 1-4. 

OWNING CONSOLES 

Passive devices are serviced on separate logical 
connections from their corresponding interactive 
consoles. Because of this, a mechanism is needed 
to associate a passive device with the console that 
enters controlling information for it. The mecha¬ 
nism used is the owning console concept. 



Terminal Terminal 


Figure 1-4. Typical Connections in the Network 
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When a passive device is defined in the network 
configuration file, an interactive console is 
identified as the owning console of the passive 
device. The method used identifies the console by 
its terminal name, as defined for the console in 
the network configuration file. An application 
program receives the name of the owning console as 
a parameter in the passive device's connection 
request, along with the terminal name of the pas¬ 
sive device. The application program also receives 
the terminal name of the console as part of the 
console's connection request, and can therefore 
associate the two devices. 

NETWORK ACCESS METHOD 
OPERATION 

Figure 1-5 shows the components of NAM as it is 
discussed in this manual. Ail of the area enclosed 
by the dotted lines comprises the Network Access 
Method. 

As NAM receives data from the network terminals or 
application programs, the data is buffered in NAM's 
buffers. (See section A.) Application programs 
use calls to AIP procedures to request and transmit 
this data. 

Inbound data from an interactive virtual terminal 
or another application is placed, unmodified, in 
nip's central memory buffers by PIP. These buffers 
form an input queue associated with the logical 
connection that originated the data. Data is 
removed from this input queue when application pro¬ 
gram AIP statements request input from the logical 
connection. The data can be translated and con¬ 
verted by NIP from ASCII to display code if the 
application program has requested such conversion; 
transparent data, as described in section 2, is 
neither edited nor translated. NIP places the 
translated or transparent data in a data buffer 
within the application program's field length. 
This data buffer is established and maintained by 
the application program. 

Output for an Interactive virtual terminal or 
another application is handled in the reverse 
manner. The application program calls an AIP pro¬ 
cedure to send data on a logical connection. The 
data is transferred from the program's field length 
to an output queue within NIP's field length. From 
there, it is placed in one of PIP's output buffers, 
according to its priority as a supervisory message, 
low priority data, or high priority data, and to 
its destination. Code conversion and translation, 
if necessary, is done by PIP. 

The files shown in figure 1-5 are maintained by 
code Independent of NAM. Named files in the figure 
are discussed briefly in various portions of this 
manual. 

APPLICATION PROGRAM CONCEPTS 

NAM requires an application program to reside at a 
separate operating system control point. This 


program contains calls to the AIP routines listed 
in appendix D and described in sections 5 and 7, 
These calls can be direct, or indirect through the 
Queued Terminal Record Manager. 

An application program begins accessing the network 
by calling NETON. It transmits data through the 
network by calling NETPUT or NETPUTF. It receives 
data through the network by calling NETGET, NETGETL, 
NETGETF, or NETGTFL. 

An application program must contain buffers for 
transmitted or received data. These buffers can be 
either unified or fragmented central memory areas. 
One buffer can be used for all logical connections, 
or many unified buffers or fragments of a buffer 
can be used for each logical connection. 

An application program sends instructions to the 
network software and receives operational infor¬ 
mation from the network software through supervisory 
messages, as described in section 3, It must 
contain procedures to formulate or process these 
messages. 

An application program can contain procedures that 
optimize its use of central memory and the control 
processor. AIP routines can make the program avail¬ 
able for rollout when the program has no data to 
process (NETWAIT), or allow the program to perform 
non network processing while waiting for completion 
of a network processing task (NETSETP and NETCHEK). 

An application program can compile statistics about 
its functioning (NETSTC) that can be examined for 
application tuning. It can also cause trace dumps 
of its network traffic (NETDBG) . The trace file 
generated can be dynamically disposed for storage, 
processing (NETREL), and application debugging. 

An application program must contain a call to NETOFF 
to terminate its access to the network. Application 
programs using the optional code controlled by 
NETDBG or NETSTC must also dispose of the local 
files created by this code. (See section 6.) 


CONNECTION PROCESSING FLOW 

The functions performed by NAM and other software 
described previously in this section can best be 
summarized by tracing the job processing involved 
for a single terminal and a single site-written 
application program. Figure 1-6 is a generalized 
version of this processing flow. Time elapses in 
the figure from top to bottom. Program processing 
begins from the left, terminal actions begin from 
the right. Dotted lines separate functions for 
each entity. When the boxes formed by solid or 
dotted lines are aligned, the functions of the 
entities Involved are related. Actions for a batch 
device (a passive device) differ from those shown 
for an interactive terminal; the first two and last 
three terminal actions are performed internally by 
the Network Validation Facility for batch devices 
based upon login information supplied for the 
device's owning console. 
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Figure 1-5. Network Access Method Components 
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Figure 1-6. Typical Application Program Processing Flow 





























SUPPORTED TERMINALS 

The network software, and therefore an application 
program, can service any real terminal compatible 
with one of the terminal classes listed in table 
1-2. Each terminal class is identified by its 
terminal class number, described in section 3 under 
Managing Logical Connections. All terminal classes 
are supported by the Interactive virtual terminal 
interface. When a mnemonic appears in table 1-2, 
it indicates the archetype terminal supported for 
the given terminal class and device type. 


The archetype mnemonics are not used by the appli¬ 
cation program in any form; the archetypes are 
described in more detail in the Network Definition 
Language reference manual, where they are identified 
by the same mnemonics. (See the preface.) 

Site-modified versions of the network software can 
service terminals in terminal classes other than 
those listed. This manual applies only to support 
of the terminal classes defined by CDC. Content of 
this manual can be valid for site-defined terminal 
classes; CDC is not responsible for deviations from 
this manual attributable to support of site-defined 
terminal classes. 


TABLE 1-2. SUPPORTED TERMINAL CLASSES 


Line Protocol 


Terminal 


Device and Archetype Terminal Mnemonlct 


Class 

Console 

Card Reader 

Line Printer 

Card Punch 

Plotter 


Asynchronous 
or X.25 PADTt 


HASP 

Blsynchronoustt 


Mode 4 
Synchronous 


2780/3780 

Blsynchronoustt 


3270 

Bisynchronous 



tA blank indicates the device type is not supported for the terminal class. 
ttPoint-to-polnt configurations only. Multidrop configurations are not supported. 
tttx.25 PAD does not support terminal class 4. 

^Terminal such as VTIOO that follows ANSI standard X3.64. 
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INFORMATION PROTOCOLS 


2 


This section describes the protocols governing 
information exchanged for communication between the 
Network Access Method (NAM) and each application 
program, and between application programs and their 
connections. This section applies only to connec¬ 
tions through NPUs. Information regarding connec¬ 
tions through CDCNET can be found in the CDCNET 
Terminal Interface Usage manual. The first portion 
of this section defines the terms and concepts 
needed to understand the description of information 
content in the remainder of this section. 

You should remember that parts of the network soft¬ 
ware are written as application programs and also 
use these protocols. Some of the features and 
options discussed in this and subsequent sections, 
therefore, do not necessarily apply to site-written 
application programs; such information is indicated 
where it is described. 

INFORMATION FLOW 

Information flow in the network is defined from the 
viewpoint of the host computer. Information coming 
to the host is said to be traveling upline; Infoi^ 
mation moving away from the host is said to be 
traveling downline. 

Information flow within a host computer is defined 
from the viewpoint of a network application program. 
Information coming to the application is said to be 
traveling upline; information moving away from the 
application is said to be traveling downline. 

STRUCTURE PROTOCOLS 

The network software uses structure protocols of 
two types: 

A logical protocol based on the concept of a 
message 

A physical protocol based on various definitions 
of a block of data 

The conditions that create a logical message and the 
conventions governing the subdivision of messages 
are influenced by the physical structure protocols 
the network uses. The events Involved in actually 
creating a message are described later in this 
section under the headings Interactive Terminal 
Input Concepts and Interactive Terminal Output 
Concepts. 

Structure protocols for CDCNET networks are de¬ 
scribed in the CDCNET, Terminal Interface Usage 
Manual. 

PHYSICAL PROTOCOLS AND NETWORK BLOCKS 

Information exchanged with the network is either: 
Data of no significance to the network software 


Control information of significance only to the 
network software 


Exchanges of control information and data between 
application programs, the network software, and a 
terminal user occur in logical messages comprising 
one or more physical network blocks. A network 
block is a physical subdivision of a logical entity. 

A network block is a grouping of information with 
known and controllable boundary conditions, such as 
length, completeness of the unit of communication, 
and so forth. Other network documentation refers 
to network blocks as network data blocks; this man¬ 
ual uses the term data block only when referring to 
network blocks that do not contain control infor¬ 
mation. 

Information exchanges between network processing 
units and host computers or between application 
programs use this physical structure protocol. 
Such exchanges occur in single network blocks. 

Information exchanges between network processing 
units use a different physical structure protocol. 
Such exchanges occur in sets of character and con¬ 
trol bytes called frames. The relationship of a 
frame to a network block is not significant to an 
application programmer; frames are not discussed in 
this section. 

Information exchanges between network processing 
units and terminal devices use a third physical 
structure protocol. Such exchanges occur in sets 
of character and control bytes called transmission 
blocks. 

Information exchanged between a network processing 
unit and a public data network use packets as the 
physical structure protocol. When the application 
communicates with a terminal or other CDC host 
applications, the relationship of a packet to a 
network block is not significant to an application 
programmer. Therefore, this relationship is not 
discussed in this section. 

However,- the relationship of a packet to a network 
block may be significant if the application is com¬ 
municating with a foreign host's application. The 
mapping of network blocks into the X. 25 protocol is 
discussed in- the Communications Control Program 
Internal Maintenance Specifications. 


LOGICAL PROTOCOL AND PHYSICAL BLOCKS 

Upline and downline information within the host and 
NPUs is always grouped into physical network blocks. 
Network data blocks are grouped into logical mes¬ 
sages. Messages exchanged between an NPU and a 
device can also be grouped into physical trans¬ 
mission blocks of one or more logical messages. 
Figure 2-1 shows these concepts. 
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Figure 2-1. Physical and Logical Information Structures 


Network blocks are restructured into other types of 
blocks at points of entrance and exit from the net¬ 
work processing units. Figure 2-2 shows these 
points as circles. 


Network Data Blocks 

A network data block is a collection of character 
bytes, analogous to a clause in English. It is a 
partially Independent unit of information and might 
need to be used with other blocks to form a message. 

A network data block can contain all or part of a 
message. Whether a message must be divided into 
several network data blocks is determined by the 
size of a network data block. 

Upline and Downline Block Sizes 

CDC-defined Interactive devices have network data 
block sizes that are multiples of 100 character 
bytes for upline data and of varying sizes for 
downline data. The last block of an upline message 
need not contain a multiple of 100 characters. 


Appllcation-to-application connections have upline 
and downline blocks of varying sizes. The upline 
block size seen by one application is the downline 
block size used by the other application. 

CDC-defined batch devices have network data block 
sizes that are multiples of 64 central memory 
words. Each such block is one mass storage physi¬ 
cal record unit (PRU) of a file. 

The network administrator establishes the appro¬ 
priate size of upline and downline network data 
blocks for each terminal device or application-to- 
appllcatlon connection when the network configura¬ 
tion file is created. Sizes are usually chosen to 
fit a single message into a single network data 
block, or to optimize use of available network 
storage, or to satisfy some other administrative 
criterion. The administrator also establishes the 
correct size for a terminal transmission block in 
the network configuration file. 

The initial size of an upline network data block is 
established by the site administrator (using the 
UBZ parameter of an NDL statement) when he or she 
defines the device or application connection that 
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Figure 2-2. Block Reassembly Points 

produces the block. Once a size is established for 
a connection, that size determines the maximum num¬ 
ber of characters an application program can receive 
as a single network data block. When an upline 
message is too long to fit into a single network 
data block, the NPU divides it into as many network 
data blocks as necessary before delivery to the 
application program. 

Appllcatlon-to-appllcation data is not split into 
smaller blocks before upline delivery if the data 
crosses a trunk line between two host nodes or if 
it is passed between two programs in the same host. 
Such data does not pass through the NPU software 
that prepares all other upline blocks. 

The initial size of a downline network data block 
is established by the site administrator (using the 
DBZ parameter of an NDL statement) when he or she 
defines the device or application connection that 
receives the block. The established size Is a 
recommended maximum for the number of characters an 


application program should send in a single network 
block. The actual maximum size of a downline net¬ 
work block is chosen by the application program 
sending the block. NAM imposes an absolute maximum 
size, however; this absolute maximum is described 
later in this section under the heading Block Buffer 
Areas. 

The maximum length used for each network data block 
to or from a device can be Independent of the ter¬ 
minal's transmission block size. For example, a 
mode 4 console cannot accept a transmission block 
containing more than a specified number of char¬ 
acters. An application program could divide a mul¬ 
tiple line display transmitted to the console of 
such a terminal into network blocks smaller than 
the buffer space of the specific terminal. However, 
the application program does not need to divide its 
network blocks. The network software reconstructs 
any of the program's network data blocks longer 
than the terminal's buffer space into several ter¬ 
minal transmission blocks of the correct size. 

An application program is advised of the upline and 
downline network data block sizes and terminal 
transmission block size defined when logical con¬ 
nection to a device occurs. Your application pro¬ 
gram can change the established upline block size 
using control information called a field number/ 
field value pair; this process is described in sec¬ 
tion 3. Your application program cannot change the 
established downline block size but can ignore it. 
Ignoring a recommended value can cause resource 
problems for the network software, particularly in 
the NPUs. 

The upline block size is enforced by the network 
software, which subdivides terminal transmission 
blocks input from a device into network data blocks 
of that size or smaller. The upline block size 
defines the largest block that NAM will deliver to 
the application program from a device. 

The downline block sizes defined are advisory 
values. That is, an application program can accept 
the size specified for a given logical connection 
when the connection is made, or ignore that speci¬ 
fication and choose its own value for maximum block 
size. If an application program transmits blocks 
larger than the downline block size, the network 
software does not subdivide them until it creates 
transmission- blocks for the terminal. 

The downline terminal transmission block size is 
also enforced by the-network software. Your appli¬ 
cation program can change the established trans¬ 
mission block size using a field number/fleld value 
pair, as described in section 3. 

Application programs should use the downline block 
sizes defined whenever possible. If the size of an 
upline or downline network data block is not appro¬ 
priate for the type of data being exchanged with a 
connection, device, you should discuss the situation 
with the network administrator who configures the 
devices being serviced. The Network Definition 
Language reference manual listed in the preface 
contains guidelines for choosing upline and downline 
network data block sizes and for selecting terminal 
transmission block sizes. 
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Block Limits 

Temporary network block storage (queuing) occurs 
for upline and downline traffic at several points 
In the network. The network admlnstrator controls 
the storage space required by controlling the net¬ 
work data block size and the number of blocks queued 
in each direction. 


The number of blocks queued depends on several 
Network Definition Language (NDL) statement param¬ 
eters. One of those parameters, the ABL parameter, 
establishes the application block limit. Another 
NDL statement parameter, the UBL parameter, estab¬ 
lishes the upline block limit. The upline block 
limit determines the number of upline blocks NAM 
queues for your program before rejecting further 
input. 

The application block limit is another device or 
application connection configuration parameter 
received by an application program (as the abl 
field value) when logical connection occurs. Your 
application program cannot send more than that 
number of downline blocks for queuing within the 
network. The use of the application block limit is 
described in section 3 as part of the data flow 
control description. 


Transmission Blocks 

Terminals send or receive data in physical groupings 
of character bytes; these groupings are called 
transmission blocks. The size of a downline trans¬ 
mission block for a specific device is also estab¬ 
lished by the network administrator (using the XBZ 
parameter of an NDL statement). The value used 
might be dictated by hardware requirements. 


Transmission blocks exchanged with X.25 devices are 
called packets and have different size and protocol 
content requirements than transmission blocks 
exchanged directly with a terminal. The network 
administrator can control some of the character¬ 
istics of packets. 

During upline transmissions from a device, the NPU 
reassembles the terminal's transmission block into 
network blocks. Each transmission block from a 
CDC-defined batch device can contain part of a 
single message, all of a single message, or several 
messages. Each transmission block from a CDC- 
defined console device can contain all of a single 
message, or several messages. 

During downline transmissions, the NPU resassembles 
network blocks into terminal transmission blocks. 
This conversion is done so that the application 
program need not be concerned that output is 
delivered in appropriately sized transmission 
blocks when the terminal cannot process blocks 
larger than a maximum size. Each transmission 
block can contain part of a single message or all 
of a single message; downline transmission blocks 
do not contain more than one message. 


INTERACTIVE TERMINAL INPUT 
CONCEPTS 

An interactive device can send or receive data in 
two modes: 

Normalized mode 

Transparent mode 

The significance of these data modes is described 
later in this section under Interactive Virtual 
Terminal Data. The following discussion does not 
apply to transparent mode data. 

In normalized mode, an interactive device transmits 
logical lines of data. Each logical line is analo¬ 
gous to an English sentence. It is a complete unit 
of information. 

The device can transmit these lines one at a time, 
or in sets. It therefore can use one of two pos¬ 
sible transmission modes. 

If the device can transmit only one character or 
one logical line in each transmission block, it is 
operating in line mode. If the device can transmit 
more than one logical line in a transmission block, 
it is operating in block mode. 

HASP, 2780/3780, and 3270 devices (terminal classes 
9, 14, 16, 17, and 18) always operate in line 
mode. Mode 4 devices (terminal classes 10 through 
13 and 15) always operate in block mode. Only 
devices in terminal classes 1 through 3 and 5 
through 8 can operate in both modes. 


Line Mode Operation 

From a terminal user's viewpoint, transmitting a 
single logical line at a time is a buffered line 
mode form of input. Buffered line mode allows the 
user to select either character-by-character or 
line-by-line transmission (some devices have 
switches to select either option) without distinc¬ 
tion. Each logical line is terminated by an end- 
of-llne indicator; this indicator might also trans¬ 
mit the line from the terminal, if the terminal 
buffers lines of input. Each logical line becomes 
a separate network message when the NPU receives it. 

When the NPU is told that an interactive device is 
operating in line mode, the NPU performs line turn¬ 
around for it. When a message is sent upline in 
this mode, the NPU begins to send any downline data 
available for the device. That is, output is 
allowed after each logical line of input. (Refer 
to the KB option for the IN command, described in 
section 3.) 

Block Mode Operation 

Some devices can transmit many logical lines in a 
single transmission block. (The terminal user 
sometimes can select or override this condition with 
a BLOCK or BATCH mode switch on the device.) Such 
devices are called block mode terminals. Mode 4 
devices, for example, are always treated as block 
mode devices. 
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Block mode terminals group logical lines in the 
terminal until the transmission key is pressed; 
these groups reach the network software as a single 
transmission block. The network software forwards 
each message to the application program as a sepa¬ 
rate transmission; the effect resembles typeahead 
entries from line mode terminals. 

Each logical line within the input transmission 
block ends with an end-of-line indicator. Each 
transmission block is terminated by an end-of-block 
indicator. 

Whether each logical line in a transmission block 
becomes a separate message or each transmission 
block becomes a single message is initially deter¬ 
mined by the network administrator through the 
device definition in the network configuration 
file. Your application program or the terminal 
user can change that mode (refer to the EL and EB 
options of the EB command, described in section 3). 

When the NPU is told an interactive device is oper¬ 
ating in block mode, the NPU does not perform line 
turnaround for it until all of its current trans¬ 
mission block is received. When the terminal is 
serviced in this mode, the NPU holds all downline 
data available for the device until it detects the 
end-of-block indicator. That is, output is allowed 
after each logical line of input only if each logi¬ 
cal line of input is transmitted in a separate 
block. (Refer to the BK and PT options for the IN 
command, described in section 3.) 

A terminal might have a block transmission key that 
does not generate the end-of-block indicator. When 
the block transmission key generates the end-of-llne 
Indicator, the terminal is operating in line mode, 
and logical lines are transmitted from the terminal 
as separate messages. 

When the transmission key does not generate either 
the currently defined end-of-llne indicator or the 
currently defined end-of-block indicator, the ter¬ 
minal user must be aware of the distinction. If 
possible, the user should change the end-of-block 
indicator to the code actually sent by the key. If 
not possible, if the code sent by the key cannot be 
determined, or if the key does not generate a code, 
then the user must enter an Indicator as the last 
data character before pressing the transmission 
key. These possible conditions exist: 

If the transmission key is pressed Immediately 
after pressing the key that generates an end- 
of-line indicator, a message is generated. This 
result is the same as if the device was opera¬ 
ting in line mode and the key generating an 
end-of-llne Indicator had been pressed, or as 
if the key generating an end-of-block indicator 
had been pressed. 

If the transmission key is pressed immediately 
after pressing the key that generates an end- 
of-block indicator, a message is generated. 
This result is the same as if the device was 
operating in line mode and the key generating 
an end-of-line indicator had been pressed, or 
as if the transmission key had generated an 
end-of-block indicator. 


If the transmission key is pressed without 
pressing an end-of-line key or end-of-block key 
as the last prior activity, an incomplete mes¬ 
sage exists. The Terminal Interface Program 
(TIP) generates an upline network data block if 
enough information was received. If a downline 
block is available for the device, the data 
remains queued while the TIP watts for comple¬ 
tion of the input transmission block. This 
situation exists until the terminal user enters 
more data, ending with either an end-of-llne or 
an end-of-block indicator. 


Physical and Logical Lines 

A logical line of input can contain one or more 
physical lines; a physical line ends when vertical 
repositioning of the cursor or carriage occurs. If 
the device recognizes a linefeed operation distinct 
from a carriage return operation, a physical line 
ends when a linefeed is entered. If no distinction 
exists between vertical and horizontal reposition¬ 
ing, a physical line is Identical to a logical line. 

A physical line of input is relevant to the network 
software only when a backspace character is proc¬ 
essed. Terminal users cannot backspace across 
physical line boundaries to delete characters in 
physical lines other than the current one. 

A logical line of input always ends when an inter¬ 
active device transmits an end-of-line or end-of- 
block indicator. An upline message is normally 
transmitted to the host as soon as a logical line 
ends. 


End-of-Line Indicators 

The end-of-line indicator is initially established 
by the network administrator when he or she defines 
the device in the network configuration file. The 
indicator is either a specific code, a code 
sequence, or a specific condition associated with 
use of a certain key or set of keys by the terminal 
operator. The default keys for generating an end- 
of-line Indicator are shown in table 2-1. 

Your application program or the terminal user can 
change this Indicator (refer to the EL command 
options, described in section 3), The NPU normally 
discards any end-of-line indicator character code 
when it detects the end of a logical line. 


Multiple Logical Lines in One Message 

For upline data from an Interactive device, the 
network administrator can configure the device so 
that the NPU Ignores the character or event that 
normally causes it to transmit a message as soon as 
a logical line ends. Instead, he or she can make 
the NPU use a different character or event to trig¬ 
ger transmission to the host. Your application 
program or the terminal user can also make this 
change (refer to the EB option of the EL command, 
described in section 3). 
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TABLE 2-1. DEFAULT MESSAGE DELIMITER AND TRANSMISSION KEYS 


Terminal 

Class 

Archetype 

Terminal 

End-of-Llne Key 

Character or 

Line Mode 
Transmission Key 

Block Mode 
Transmission Key 

1 

Teletype Model 30 
series 

RETURN 

RETURN 

CTRL and D 

2 

CDC 713, 722-10, 

751, 752, 756 

RETURN or 

CARRIAGE RETURN 

RETURN or 

CARRIAGE RETURN 

SEND or 

CONTROL and D 

3 

CDC 721 

NEXT 

NEXT 

NEXT 

4 

IBM 2741 

RETURN 

RETURN 

None 

5 

Teletype Model 40-2 

RETURN 

RETURN 

SEND 

6 

Hazeltine 2000 

CR 

CR 

SHIFT and XMIT 
or CTRL and D 

7 

DEC VT 100 or 

CDC 722-30 

CARRIAGE 

RETURN 

CARRIAGE 

RETURN 

CTRL and D 

8 

Tektronix 4014 

RETURN 

RETURN 

CTRL and D 

1 thru 3 

5 thru 8 

X. 25 packet assembly/ 
disassembly (PAD) 
console device 

Same as above 

Packet 

transmission 

key 

CTRL and D 

9 

HASP (postprint) 

Variable 

Variable 

None 

10 

CDC 200 User Terminal 

RETURN 

None 

SEND 

11 

CDC 714-30 

NEW LINE 

None 

ETX 

12 

CDC 711 

NEW LINE 

None 

ETX 

13 

CDC 714-10/20 

NEW LINE 

None 

ETX 

14 

HASP (preprint) 

Variable 

Variable 

None 

15 

CDC 734 

NEW LINE 

None 

SEND 

16 

IBM 2780 

End of card 

End of card 

None 

17 

IBM 3780 

End of card 

End of card 

None 

18 

19 thru 

27 

IBM 3270 

Reserved for CDC use 

ENTER 

None 

None 

28 thru 

31 

Site-defined 

Unknown 

Unknown 

Unknown 


This option allows the terminal user to pack many 
logical lines into one upline network block. Each 
line includes the end-of-llne Indicator as a data 
character that terminates it. This is a form of 
line mode, because the host receives only one 
message. From the terminal user^s viewpoint, one 
message is many logical lines. 


End-of-Block Indicators 

The end-of-block indicator is initially established 
for the device by the network administrator when he 


or she defines the device in the network configura¬ 
tion file. The indicator is either a specific code, 
a code sequence, or a specific condition associated 
with use of a certain key or set of keys by the 
terminal operator. 

The default keys for generating an end-of-block 
indicator are shown in table 2-1. In X.25 packet- 
switching networks, the packet transmission condi¬ 
tion is always the end-of-block indicator. 

When the device is not operating in block mode, the 
end-of-block indicator has the same effect as an 
end-of-llne indicator. 


2-6 


60499500 T 



























Your application program or the terminal user can 
change the end-of-block indicator (refer to the KB 
command, described in section 3). This Indicator 
normally is discarded when the last message from the 
device is sent upline. 


INTERACTIVE TERMINAL OUTPUT 
CONCEPTS 

A downline message can contain no logical lines (an 
empty block or a transparent mode block) or many 
logical lines of output. Each logical line can 
contain many physical lines of output. 

A logical line of output ends when the application 
program embeds a code or set of bytes for that 
purpose in the message, or when the block containing 
the line ends. A downline message ends when an 
application program indicates that condition. 

Because downline messages can always contain more 
than one logical line, an interactive device can 
always receive the output equivalent of a multiple- 
message block mode input transmission. The appli¬ 
cation program can group logical lines as necessary 
to achieve that effect. 

If a message fits into a downline network data 
block, the block becomes a single-block message. 
If one downline message cannot be fit- into a single 
network data block, the application program can 
split it into as many blocks as necessary. An 
application program generally sends a single 
message (consisting of as many logical lines as 
necessary) as the response to one input message 
from an interactive device. 


BATCH DEVICE DATA 

Batch devices can be serviced as site-defined device 
types through the interactive virtual terminal 
Interface described later in this section. A sep¬ 
arate set of Interface protocols also exists for 
batch devices serviced by CDC-wrltten Terminal 
Interface Programs and application programs. 

These programs require large amounts of data to be 
exchanged between a host computer's mass storage 
devices and CDC-defined batch devices. Such batch 
data is therefore assembled into messages of one or 
more network data blocks. Each network data block 
contains one or more mass storage physical record 
units (PRUs). Because only the CDC-written Remote 
Batch Facility can use the special Interface for 
CDC-defined batch devices-, the remainder of this 
manual does not discuss the requirements this 
interface imposes on batch data or batch device 
support. 


APPLICATION-TO-APPLICATION INPUT 
AND OUTPUT CONCEPTS 

Application programs within the same host exchange 
data by transferring the contents of 60-blt central 
memory words between control points. A program can 
create a connection to Itself and exchange data on 
that connection. 


Application programs in different hosts exchange 
data by transferring the contents of 8-blt bytes 
through the network, as if the data were sent to or 
received from an interactive virtual terminal. 

Application programs can exchange data only in 
transparent mode. Upline and downline messages are 
not subdivided into logical lines. Embedded codes 
are not used to terminate lines or network data 
blocks within the messages. 


INFORMATION IDENTIFICATION 
PROTOCOLS 

CDC network host software uses four general con¬ 
ventions for identifying network blocks. These 
conventions indicate the following things to the 
application program sending or receiving the block: 

The kind of message of which the block is a 
part; this is called the message type. 

The kind of information within the block; this 
is called the application block type. 

The areas of host central memory containing the 
block and containing information describing the 
block; these are called the block buffer areas. 

'The source or destination of the block; these 
connection identifiers are called the applica¬ 
tion connection number and the application list 
number. 

The following subsections describe these conven- 
t ions. 


APPLICATION PROGRAM MESSAGE TYPES 

An application program message is a complete logical 
unit of information, comprising one or more physical 
network blocks. A message can be a line of data to 
or from a teletypewriter, a mass storage file, a 
service request to NAM, or a screen of information 
for a cathode ray tube. 

There are two kinds of application messages, data 
and supervisory. Data messages convey Information 
of significance only to a device user or to another 
application program. Data messages can consist of 
more than one network data block. 

Supervisory messages convey information of signifi¬ 
cance only to the network software. Supervisory 
messages consist of only one network block. 

Supervisory messages are used by an application 
program to control data messages between itself and 
logical connections. 


APPLICATION BLOCK TYPES 

The network block is the basic unit of information 
exchange for the application program. There are 
several types of network blocks that an application 
program can exchange. Each type has an identifying 
application block type number assigned to it. The 
following types exist: 
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Mull blocks, which are dummy input blocks indi¬ 
cating the absence of any data or supervisory 
information. These blocks have an application 
block type number of 0. 

Blocks containing portions of data messages, but 
not terminating those messages. These blocks 
have an application block type number of 1; such 
blocks are called BLK blocks in other network 
documentation. 

Blocks that terminate data messages. These 
blocks can Include physically empty blocks when 
such blocks convey logical information. Blocks 
that terminate data messages have an application 
block type number of 2; such blocks are called 
MSG blocks in other network documentation. 

Blocks constituting supervisory messages. These 
blocks have an application block type number of 
3; such blocks Include the information in blocks 
called CMD, BACK, BRK, ICMD, ICMDR, and other 
acronyms in some network documentation. 

Blocks containing portions of qualified data 
messages, but not terminating those messages. 
These blocks have an application block type 
number of 6; such blocks are called QBLK blocks 
in other network documentation. 

Blocks that terminate qualified data messages. 
These blocks can include physically empty 
blocks when such blocks convey logical 
information. Blocks that terminate qualified 
data messages have an application block type 
number of 7; such blocks are called QMSG blocks 
in other network documentation. 


Qualified data can be used only on application-to- 
appllcation connections. Such data has no special 
significance to the CDC network software. Quali¬ 
fied data is intended for application programs in 
order for such programs to communicate control 
information among themselves that is outside the 
data stream but synchronous with it. For example, 
user identification information (qualified data) 
placed before data in transferring files. 

Blocks with an application block type of 6 or 7 
cannot be sent or received on the logical 
connection between blocks with an application block 
type of 1 or 2. Qualified data can only be sent or 
received after an unqualified message ends or 
before an unqualified message begins. 


BLOCK BUFFER AREAS 

All network blocks are exchanged between the appli¬ 
cation program and the network software using two 
kinds of buffers: 

The block header area 

The block text area 


Block Header Area 

Block header areas each contain a 60-bit word 
describing the contents of a corresponding text 
area. This block header word accompanies the block 
in the corresponding block text area during the 
exchange between the application program and NAM. 

For downline blocks, the application program creates 
the block header and NAM interprets it. For upline 
blocks, NAM creates the block header and the appli¬ 
cation program interprets it. 

Because the contents of the header word depend on 
the contents of the text area, the header word for¬ 
mats are described in this manual after the text 
area content protocols are described. To simplify 
the header area descriptions, they are presented in 
four separate formats: 

For upline network data blocks 

For downline network data blocks 

For upline supervisory message blocks 

For downline supervisory message blocks 


Block Text Area 

A block text area is separately addressed from its 
header area and need not be contiguous to it. The 
text /area contains the single network block 
described by the header word in the header area. 

Text areas can be of varying length, as necessary 
to accommodate various block lengths. The text area 
has a maximum length expressed as a whole number of 
central memory words. Text areas can be up to 410 
central memory words long. 

The length of the text area used by the application 
program is described to the network by the applica¬ 
tion program. The text area length must be calcu¬ 
lated from the maximum length of the blocks it will 
contain. 

Block length is distinct from text area length. 
The length of a block depends on the type and use 
of the block. 

Null blocks have zero length and do not require any 
central memory words for their text area. Other 
block types have lengths expressed in character byte 
units, although the bytes need not actually contain 
characters. 

Blocks are always a whole number of character units 
long but do not have to be a whole number of central 
memory words long. Not all words in the text area 
used for a given block need to be filled with 
meaningful information. 

Supervisory message blocks are 1 through 410 words 
long. Data blocks have lengths of zero up to the 
maximum number of characters that can fit in the 
maximum text area of 410 words, or 2043 characters, 
whichever occurs first. 


2-8 


60499500 T 



Downline messages containing more characters than 
the text area can hold must be divided into several 
network data blocks. Each such block must fit into 
the text area. Each of these blocks should also 
meet the network block size requirement and must be 
transmitted separately. 

Upline data blocks can be truncated to fit into the 
existing text area. Alternatively, the application 
program can use a large text area for large blocks 
and a small text area for small blocks. 

CONNECTION IDENTIFIERS 

Two parameters identify and control the routing of 
messages: 

The application connection number 

The application list number 

Both parameters are used in AIP calls that fetch 
incoming network data blocks. The application con¬ 
nection number is used in the block header words of 
outgoing blocks. 

Application Connection Number 

The application connection number is a 12-blt inte¬ 
ger used to address a particular logical connection. 
The connection number can be used as an index into 
a control structure (for example, the number of a 
connection could be the ordinal of a corresponding 
device table) or used in any other manner the 
application chooses. 

These connection numbers are assigned serially by 
NAM for each application program. Numbers that 
become available because of disconnections are 
reassigned to subsequent connections. 

A connection number of zero indicates the control 
connection on which asynchronous supervisory mes¬ 
sages are sent and received. (See Supervisory Mes¬ 
sage Content and Sequence Protocols, later in this 
section.) 

Application List Number 

NAM permits an application program to group connec¬ 
tions with similar processing requirements into 
numbered lists. This is an efficiency feature, 
relieving the application of the need to specify 
individual connections each time upline block proc¬ 
essing is required. Instead, when a request is 
made for a block from a connection on a list, any 
device or application program connections with empty 
input queues are automatically skipped and a block 
from the first nonempty queue is returned. A single 
null block is returned when none of the connections 
on the list have any input queued. 

This feature can be used in many kinds of list 
structures. For example: 

An application program must process input from 
devices with large -network block sizes (such as 
interactive graphics terminals in a specific 


terminal class) differently than input from 
devices with small block sizes. This processing 
occurs Ln different portions of the program 
code; therefore, the application program assigns 
the devices using large blocks to list 1 and 
the devices using small blocks to list 2. 

An application program treats all devices the 
same and must process blocks from them on an 
equal basis. Accordingly, it assigns them all 
to the same list. 

An application program services terminals in 
four geographical areas; each must be treated 
separately because of varying state laws. 
Accordingly, they are assigned to lists 1 
through 4. 

An application program services devices that 
should be treated the same, but with the fol¬ 
lowing complication: when the application has 
received a block from a particular terminal, it 
must perform some time-consuming function that 
prevents it from immediately processing another 
block from the same terminal. Accordingly, the 
application places all connections on list 1 and 
issues an input request on list 1. When a block 
for connection x is returned, it temporarily 
inhibits receipt of data on connection x before 
it issues the next input request. When it can 
accept another data block from the terminal 
using logical connection x, the application 
program sends a supervisory message to reverse 
the effect of the temporary inhibition. 


The parameter used for this kind of processing is 
called the application list number. The application 
list number is an integer from 0 through 63 speci¬ 
fied by the application program when it accepts a 
connection. NAM links message input (upline) queues 
of all connections that have been assigned the same 
list number. An application program can request 
blocks from these linked queues in rotation (with¬ 
out specifying individual connections) by including 
the assigned application list number in a NETGETL 
or NETGTFL statement (described in section 5). 

Each list number identifies one connection list. A 
connection list can be viewed as a table of connec¬ 
tion numbers. These connection numbers are entered 
in the table in the order in which the application 
program assigns the connections to the list. When 
the list is scanned for input from a connection, 
the connections are examined in the order in which 
they are entered in the table. 

The application program explicitly assigns the list 
number to each logical connection when the connec¬ 
tion is established. The logical connection cor¬ 
responding to application connection number zero 
already exists when the application is connected to 
the network. For this reason, application connec¬ 
tion number zero is automatically assigned to 
application list number zero without program inter¬ 
vention. 

The application program does not have to maintain 
any tables associating connection numbers and list 
numbers. The application program need not use list 
processing at all. 
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DATA MESSAGE CONTENT AND 
SEQUENCE PROTOCOLS 

Data blocks consist of 1 through 410 60-bit words 
or 1 through 2043 8-bit or 12-bit bytes. The 
fields within these blocks convey information to or 
from the terminal user. Data blocks have associ¬ 
ated block header words. These header words convey 
information to the network software concerning the 
contents of the corresponding text area buffer. 

Data blocks are sent and received through the 
Application Interface Program routines described in 
section 5. The application program fetches data 
messages one block at a time. When the connection 
queue is empty, a null block with an application 
block type of zero is returned. 

The network software provides a mechanism - for the 
application program to determine when data blocks 
are queued. When a call to an AIP routine is 
completed, a supervisory status word at a location 
defined by the application program is updated to 
indicate whether any data blocks are queued. As 
long as the application program continues to make 
calls to AIP routines, it can test the supervisory 
status word periodically (instead of attempting to 
fetch null blocks from all application connection 
numbers). The supervisory status word and the use 
of NETWAIT are described in section 5, 

The protocols for data message text and the use of 
the text area buffer depend on whether the logical 
connection is with another application program, an 
Interactive virtual terminal device, or a passive 
batch device. Blocks exchanged with other applica¬ 
tion programs in the same host have the fewest 
requirements and most flexible structure. Blocks 
exchanged with CDC-defined batch devices using the 
special batch device protocol have the most re¬ 
quirements and the least flexible structure. 

Requirements for blocks exchanged with other appli¬ 
cation programs in the same host are covered in the 
figures later in this section, and in section 3. 
Blocks exchanged between application programs are 
groups of binary character bytes with no parity, 
equivalent to transparent mode data. Such blocks 
can use the eighth bit of an 8-blt byte as data and 
need not have the transparent mode bit set in their 
block header; see the decriptions of transparent 
mode and block header word content later in this 
section. 

The requirements for exchanging blocks with inter¬ 
active virtual terminal devices are described 
below. Requirements for blocks exchanged with 
batch devices through the special batch device 
Interface are not described because that interface 
is available only to CDC-written software. 

Data message content and sequence protocols for 
CDCNET networks are described in the CDCNET Ter¬ 
minal Interface Usage Manual. 

INTERACTIVE VIRTUAL TERMINAL DATA 

An interactive virtual terminal can be either a 
CDC-defined console device or a site-defined 
device. An interactive virtual terminal can send 
and receive data in two modes: normalized mode and 
transparent mode. The format and content of data 
in these modes is described later in this sub¬ 
section. The characteristics of an interactive 


virtual terminal depend on which data exchange mode 
is currently used. 

In normalized mode, the characteristics of an 
interactive virtual terminal are as follows: 

Input and output can occur simultaneously. 

A page of output has infinite (no physical) 
width; logical lines are divided automatically 
as needed to fit the physical line restrictions 
of the device. 

A page of output has infinite (no physical) 
length; sets of logical lines are divided auto¬ 
matically as needed to fit the physical 
restrictions of the device page. 

A logical line of output cannot be longer than 
a single network block; a single message can 
contain an infinite number of logical lines. 

Characters are either 7-blt ASCII codes using 
zero parity (bit 7, the eighth bit, is always 
zero in upline data and ignored in downline 
data), or 6-bit display codes with no parity. 

Logical lines of input are terminated by a 
changeable character or condition; this ter¬ 
minator is the end-of-llne or end-of-block 
Indicator described earlier in this section. 
The input terminator Is not part of the data 
seen by an application program unless the 
full-ASCII feature is used (this is explained 
later in this subsection and in section 3 where 
the FA command is described). 

Logical lines of output are terminated by an 
ASCII unit separator character code (US, repre¬ 
sented by the hexadecimal value IF) or the end 
of a zero-byte terminated record. The applica¬ 
tion program places this terminator in the data. 

No cursor positioning actions are required to 
acknowledge receipt of input, and no timing 
adjustments need to be made at the end of phys¬ 
ical output lines. 

Logical lines can be divided into physical 
lines by embedding optional format control 
characters in downline blocks. 

In transparent mode, the characteristics of an 
interactive virtual terminal are as follows: 


Input and output can occur simultaneously. 


A page 
width. 

of 

output 

has 

infinite 

(no physical) 

A page 
length. 

of 

output 

has 

infinite 

(no physical) 


Characters are either 7-bit codes using zero 
parity (bit 7, the eighth bit, is always zero 
in upline data and Ignored in downline data), 
or codes of a terminal-dependent code set with 
terminal-dependent parity. 

Messages of input are terminated by a change¬ 
able character or condition; this terminator is 
one of the message or mode delimiters described 
later in this section. The mode delimiter is 
not part of the data seen by an application 
program. 
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Messages of output are terminated by a condition 
or event chosen by an application program (each 
network block is separately designated as 
transparent or normalized when sent). 

Cursor positioning actions might be required, 
and timing adjustments might need to be made at 
the end of physical output lines. 


Line Turnaround Convention 

The interactive virtual terminal concept imposes 
some conventions on the content and sequencing of 
blocks exchanged with an interactive device. The 
primary convention of block sequencing involves the 
direction and time of block transmission. 

The application program can service an interactive 
device on a connection as if the device always 
operates in a full-duplex mode. That is, input and 
output can occur Independently; the terminal user 
can enter several logical lines at once (an opera¬ 
tion called typeahead), without waiting for a 
response to each line. 

Application program input and output need not 
alternate. However, some devices cannot actually 
operate that way. To prevent a loss of synchroni¬ 
zation between input and output at such devices, a 
line turnaround convention exists. This convention 
consists of the following events. 

After a block of type 2 (the end of a message) is 
sent to a device, no more blocks should be sent 
downline until at least one block is input from the 
same device. An application program therefore 
should never send the last block of a message down¬ 
line until it is ready to wait for input. 

A network data block of type 2 has special signifi¬ 
cance to the network software during output to an 
interactive device. When such a block is the last 
block of the output stream, the network software: 

Unlocks the keyboard of an interactive device 
being serviced as terminal class k (an IBM 
2741). 

Sends an X-ON code to start an automatic paper 
tape input mechanism, if one has been defined 
as the input mechanism for the device. Paper 
tape operation is explained in more detail in 
section 3 where the IN and OP commands are 
described. 

Starts polling devices in terminal classes 10 
through 13 and 15 (mode 4 consoles), and 
terminal class 18 (3270 consoles). 

If the terminal is a half-duplex device, such as a 
2741 or a paper tape reader/punch, it must enter 
input before the network software will deliver 
additional output messages. Other devices are not 
subject to this restriction. 


The requirement for an input block after a block of 
type 2 is output can be satisfied in several ways 
by terminal operators. An empty input line can be 
entered and will reach the application program as a 
block of type 2 but containing nothing. A line 
containing data can be entered and will reach the 
application program as one or more network data 
blocks. 

Devices can interrupt output by entering input. 
When this occurs, the network software stops the 
output until the terminal user completes the input 
(using an end-of-line or end-of-block Indicator) . 
Output then resumes at the next character of the 
current physical and logical line. 

INTERACTIVE VIRTUAL TERMINAL 
EXCHANGE MODES 

The conventions of block content depend on the mode 
in which the block is exchanged. There are two 
possible exchange modes, normalized mode and trans¬ 
parent mode* The latter is referred to in other 
documentation as binary mode* This manual uses 
transparent mode to indicate exchange of a block 
that is not in normalized mode* 


Normalized Mode Operation 

The interactive virtual terminal interface assembles 
message character streams into upline network data 
blocks from terminal transmission blocks. It dis¬ 
assembles character streams from downline network 
data blocks, reassembling them Into terminal trans¬ 
mission blocks. 

The assembly operation is controlled by the termi¬ 
nation of logical lines. The disassembly operation 
can be controlled by the termination of messages. 
The disassembly operation can also be modified by 
format control characters embedded in each block, 
and by the page width defined for the device (refer 
to the PW command in section 3), 


End of Logical Lines in Input 

Logical lines reach an application program as one 
or more network data blocks. Logical lines usually 
end when a message ends and do not contain the 
character or code sequence defined as the end-of- 
line or end-of-block key. 

However, two special cases exist. Logical lines do 
contain the end-of-line or end-of-block codes when 
the device is operating in full-ASCII editing mode 
(described later in this section) . Logical lines 
also contain the end-of-line code when the end-of- 
line key is changed to be the default end-of-block 
key for the device (see the EB option of the EL 
command described in section 3). In the latter 
case, the transmission block becomes a message, and 
the logical lines within it have no effect on con¬ 
struction or type of network data blocks. 
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Logical and Physical Lines in Output 

The application program does not need to equate a 
logical line of output to a complete message nor 
does it need to create a separate network block for 
each physical line of output. A single logical line 
can contain many complete physical lines. A single 
block can contain many complete logical lines, and 
a message can be one or many such blocks. A phys¬ 
ical or logical line cannot, however, be continued 
from one block to another. 

Logical lines within downline blocks are ended by 
an end-of-line indicator. Unlike the end-of-llne 
indicators used In upline blocks, downline blocks 
always contain codes for the end-of-line function; 
the codes used downline are always the same and 
usually differ from the codes used upline. The 
downline end-of-line indicator varies according to 
the application character type of the block; appli¬ 
cation character types are described later in this 
section. Bytes used to store indicators must be 
included when determining the number of characters 
comprising a downline block. 

The end-of-line indicator in 60-bit character bytes 
(application character type 1) is determined by the 
programs exchanging the block. No predefined end- 
of-line indicator exists for that application char¬ 
acter type. 

The end-of-line indicator in blocks using 8-blt 
characters in 8-blt or 12-bit bytes (application 
character types 2 or 3) is determined by whether the 
block is sent in normalized mode or transparent 
mode (described later in this section). In trans¬ 
parent mode, no end-of-line indicator exists. In 
normalized mode, the end-of-llne indicator is the 
ASCII unit separator character US. 

The end-of-line indicator in blocks using 6-blt 
character bytes (application character type 4) is 
12 to 66 bits of zero; these bits are right- 
justified to fill the last central memory word 
Involved. This convention makes each logical line 
the equivalent of a zero-byte terminated logical 
record. 

The 6-blt option requires a right-justified 12-bit 
byte in. at least one central memory word. On com¬ 
puters using the 64-character set, the colon is 
represented in 6-blt display code by six zero bits. 
On such systems, if the application needs to send 
colons to the terminal console in 6-bit display 
code, care must be taken to make sure that a string 
of colons is not interpreted as an end-of-line 
indicator. A colon preceding the end-of-llne indi¬ 
cator is considered as part of the indicator and not 
as a colon when it occupies one of the two right¬ 
most character positions in the next-to-last central 
memory word of the block or any of the eight left¬ 
most positions in the last word of the block. 

All predefined end-of-llne indicators embedded 
within a block are discarded by the network soft¬ 
ware and produce no characters on the console output 
device. The network software can perform carriage 
or cursor repositioning when an end-of-llne indica¬ 
tor is encountered; this operation is described 
later in this section under Format Effectors. 


Upline Character Sets and Editing Modes 

The network protocol permits entry from a device of 
codes less than or equal to 8 bits per character; 
however, a normalized mode character always reaches 
an application program as one of the 128 ASCII 
characters defined in appendix A. Receipt of an 
entered character by the application program depends 
on the editing functions performed by the TIP. 
Three editing modes exist for the TIP when it proc¬ 
esses normalized data: 

Complete interactive virtual terminal editing 
mode 

Special editing mode 
Full-ASCII mode 


Devices always begin a connection with the network 
in normalized mode. The initial upline editing mode 
is established for each device when the device is 
connected to the host. This mode is complete 
editing. The application program or the terminal 
user can change that mode using the SE or FA 
commands, described in section 3. 


Complete Editing 

During complete editing operations, the following 
hexadecimal character codes cannot be received by 
the network application program: 

00 (the ASCII character NUL) 

OA (the ASCII character LF) 

7F (the ASCII character DEL) 

The backspace character code currently defined 
for the device (see the BS command'in section 3) 

The end-of-line character currently defined for 
the device (see the EL command in section 3) 

The end-of-block character currently defined 
for the device (see the EB command in section 3) 

The following hexadecimal character codes cannot be 
received, if entered at certain points in a message: 

02 (the ASCII character STX), if entered as the 
first character of a message 

11 (the ASCII character DCl) if it follows an 
end-of-line or end-of-block character and the 
TIP is supporting output control for the device 
(see the Y option of the OC command in section 
3) 

13 (the ASCII character DC3) if it follows an 
end-of-line or end-of-block character and the 
TIP is supporting output control for the device 
(see the Y option of the OC command in section 
3). 
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13 (the ASCII character DC3) if It follows an 
end-of-llne or end-of-block character and the 
input mechanism is known to be a paper tape 
reader (see the PT option of the IN command in 
section 3) 

The user-break-1 and user-break-2 character 
codes currently defined for the terminal, if 
entered as the only character in a message (see 
the B1 and B2 commands in section 3) 

The abort-output-block character code currently 
defined for the terminal, if entered as the 
only character in a message (see the AB command 
in section 3) 

The network control character currently defined 
for the terminal when it follows an end-of-line 
or end-of-block character or when it is used 
for such purposes as page turning (see the CT 
command and the Y option of the PG command in 
section 3) 

The currently defined cancel input character is 
always received at the end of the logical line it 
cancels. This character is not data. 


Special Editing 

Special editing takes precedence over complete 
editing. Special editing cannot occur if the ter¬ 
minal operates in block mode. 

When special editing occurs, linefeed codes and the 
currently defined backspace code are forwarded to 
the application program as data. The network soft¬ 
ware sends appropriate responses to the device when 
it receives these codes. 

During special editing operations, the following 
hexadecimal character codes cannot be received by 
the network application program: 

00 (the ASCII character NUL) 

7F (the ASCII character DEL) 

The end-of-line character currently defined for 
the device (see the EL command in section 3) 

The end-of-block character currently defined 
for the device (see the EB command in section 3) 

The following hexadecimal character codes cannot be 
received, if entered at certain points in a message: 

11 (the ASCII character DCl) if it follows an 
end-of-line or end-of-block character and the 
TIP is supporting output control for the device 
(see the Y option of the OC command in section 
3) 

13 (the ASCII character DC3) if it follows an 
end-of-line or end-of-block character and the 
TIP is supporting output control for the device 
(see the Y option of the OC command in section 
3). 

13 (the ASCII character DC3) if it follows an 
end-of-llne or end-of-block character and the 
input mechanism is known to be a paper tape 
reader (see the PT option of the IN command in 
section 3) 


02 (the ASCII character STX), if entered as the 
first character of a message 

The user-break-1 and user-break-2 character 
codes currently defined for the terminal, if 
entered as the only character in a message (see 
the B1 and B2 commands in section 3) 

The abort-output-block character code currently 
defined for the terminal, if entered as the only 
character in a message (see the AB command in 
section 3) 

The network control character currently defined 
for the terminal when it follows an end-of-line 
or end-of-block character or when it is used 
for such purposes as page turning (see the CT 
command and the Y option of the PG command in 
section 3) 

The currently defined cancel input character is 
always received at the end of the logical line it 
cancels. This character is not data. 


Full-ASCII Editing 

Full-ASCII editing takes precedence over special 
editing or complete editing. When full-ASCII edit¬ 
ing occurs, almost all codes are forwarded to the 
application program as data. The network software 
does not perform actions at the terminal when it 
receives the codes for backspace, abort-output- 
block, cancel input message, user-break-1, or user- 
break-2. These codes and the end-of-line and end- 
of-block indicator codes are sent upline as data. 

During full-ASCII editing operations, the following 
hexadecimal character codes cannot be received by 
Che network application program: 

00 (the ASCII character NUL) if it occurs after 
the end-of-line or end-of-block indicator 

OA (the ASCII character LF) if it occurs after 
the end-of-line or end-of-block indicator 

7F (the ASCII character DEL) if it occurs after 
the end-of-line-or end-of-block indicator 

The network control character currently defined 
for the terminal if it occurs after the end-of- 
line or end-of-block indicator or when it is 
used for such purposes as page turning (see the 
CT command and the Y option of the PG command 
in section 3) 


The following■hexadecimal character codes cannot be 
received if entered at certain points in a message: 

11 (the ASCII character DCl) if it follows an 
end-of-line or end-of-block indicator and the 
TIP is supporting output control for the device 
(see the Y option of the OC command in section 
3) 

13 (the ASCII character DC3) if it follows an 
end-of-llne or end-of-block indicator and the 
TIP is supporting output control for the device 
(see the Y option of the OC command in section 

3) 
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13 (the ASCII character DC3) if it follows an 
end-of-line or end-of-block indicator and is 
explicitly supporting paper tape input from the 
device (see the FT option of the IN command in 
section 3). 

The currently defined cancel input character is 
always received as the last character of the logical 
line it ended. This character is data. 


Downline Character Sets 

The network protocol permits transmission from a 
network application program of any character code 
less than or equal to 8 bits. If the application 
program uses one of the application character types 
that permits transmitting an 8-bit code (application 
character types 2 and 3), it cannot use the upper 
(eighth) bit for data unless it is transmitting in 
transparent mode. 

In normalized mode, the application program can only 
use the 128 ASCII characters defined in appendix 
A. If the application program transmits a 7-blt 
ASCII code, it cannot use the upper (eighth) bit 
for parity; the network ignores the eighth bit in 
downline normalized mode data. 

Receipt of a transmitted character by the device 
depends on the editing functions and character 
transformations performed by the TIP. In addition 
to character codes altered during the translation 
and substitution operations described elsewhere in 
this section and in appendix A, the hexadecimal 
character code IF (the ASCII character US used as a 
downline block end-of-line indicator) cannot be 
received by a device when the application program 
transmits a block in normalized mode. 


Page Width and Page Length 

The application program receives an indication of 
the page width and page length in effect for a 
device when connection with the device first occurs. 
The application program or the terminal user can 
change the page width and page length in effect for 
a device. 

The Terminal Interface Program uses the page length 
defined for the device to format physical lines 
into physical pages or screens of output. The Ter¬ 
minal Interface Program uses the page width value 
to transform logical lines of downline data into 
physical lines of output. 

For console devices defined as having hardcopy out¬ 
put mechanisms (see the PR option of the OP command 
in section 3), a logical line of downline data con¬ 
taining more characters than the page width value 
permits is divided into singly spaced physical 
lines. These physical lines are equal to or shorter 
than the page width in effect and are displayed 
successively. 

For all console devices, the page width is used as 
part of the line-counting algorithm to determine 
the page length. Each logical line is examined to 
determine how many multiples of the page width (how 
many physical lines) it contains. Each complete or 
partial multiple counts as one line when the TIP 
determines the page length. 


Line counting begins at the beginning of each down¬ 
line message. The line counter is reset to zero 
each time the page length of the terminal is 
reached, each time any input occurs, or when page 
turning occurs during page waiting operation. Refer 
to the PG, PW, and PL commands in section 3. 

The physical line width of the device might be 
smaller than the page width defined for the device. 
When this happens, the effect of sending a logical 
line of downline data containing more characters 
than the physical line width permits depends on the 
terminal hardware. 


Format Effectors 

An application program can control the presentation 
of the characters within a data block by Indicating 
that the block contains format effectors. If the 
application program chooses to do this, the first 
character of each logical line within the block 
becomes a format effector. Format effector charac¬ 
ters cause predefined formatting operations when 
the block is delivered to the device. The network 
software discards these characters after interpre¬ 
tation; therefore, these characters do not appear 
on the interactive terminal output device. 

You must Include format effector characters when 
determining the number of characters comprising the 
block. Format effector characters are excluded from 
page width calculations. 

Tables 2-2 and 2-3 describe the predefined opera¬ 
tions produced by each format effector character of 
each terminal class. The Terminal Interface Program 
performs the predefined format effector operation 
by inserting the codes for the characters indicated 
in the tables in place of the discarded format 
effector character code. The inserted terminal 
codes are those of characters in the ASCII set 
described in appendix A, with the exception that NL 
indicates the terminal-defined new-line code 
sequence. 

Numbers preceding codes indicate the number of times 
the codes are repeated in the Inserted sequence. 
Each line output to a console in terminal classes 9 
through 18 leaves the cursor positioned at the 
beginning of the next physical line. Processing of 
the next line takes this Into account. 

The format effector characters for clear screen and 
home cursor operations (* and 1) receive special 
treatment by the Terminal Interface Program when it 
is performing a page wait function for the terminal. 
(See the PG command in section 3.) If these char¬ 
acters are encountered when the TIP has output only 
part of a page, the TIP pauses for terminal operator 
acknowledgment of the partial page. When acknowl¬ 
edgment occurs, the format effector functions are 
performed and output continues automatically. This 
pause occurs without application program action or 
knowledge. 

If the application program does not Indicate the 
existence of format effectors, the first character 
of each logical line does not act as a format 
effector. These characters are output normally but 
are preceded by the character codes necessary to 
space one line before output. These default line- 
spacing codes are the ones substituted when a blank 
is used as a format effector. 
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TABLE 2-2. CCP FORMAT EFFECTOR OPERATIONS FOR ASYNCHRONOUS AND X.25 CONSOLES 


Terminal 

Class 

Format 

Effector 

General Physical Operation 

Is Infinite Page 
Length Declared? 

Does Output 
Follow Previous 
Input 

Code Substituted on 
Output Mechanismt 

Display or 
Printer 

Paper Tape 

1 

blank 

Space 1 line before output. 

Does not matter 

Yes 

CR 

CR 





No 

CR, LF 

CR, LF 


0 

Space 2 lines before output. 

Does not matter 

Yes 

CR, LF 

CR, LF 





No 

CR, 2LF 

CR, 2LF 


- 

Space 3 lines before output. 

Does not matter 

Yes 

CR, 2LF 

CR, 2LF 





No 

CR, 3LF 

CR, 3LF 


+ 

Position to start of current 

Does not matter 

Yes or No 

CR 

CR 



line before output. 






* 

Position to top of form or 

Yes 

Yes 

CR, 5LF 

CR, 5LF 



home cursor before output. 


No 

CR, 6LF 

CR, 6LF 




No 

Yes or No 

Calculat 

ed by TIP 


1 

Position to top of form or 

Yes 

Yes 

CR, LF 

CR, 5LF 



home cursor and clear screen 


No 

CR, 6LF 

CR, 6LF 



before output. 








No 

Yes or No 

Calculat 

ed by TIP 



Do not change position before 

Does not matter 

Yes or No 

None 

None 



output. 







Space 1 line after output. 

Does not matter 

Yes or No 

CR,LF 

CR,LF, 







DC3, 







3NUL 


/ 

Position to start of current 

Does not matter 

Yes or No 

CR 

CR, 



line after output* 




DC3, 







3NUL 


Any other 

Space 1 line before output. 

Does not matter 

Yes 

CR 

CR 


ASCII 



No 

CR, LF 

CR, LF 


character 






2 

blank 

Space 1 line before output. 

Does not matter 

Yes 

CR 

CR 





No 

CR, LF 

CR, LF 


0 

Space 2 lines before output. 

Does not matter 

Yes 

CR, LF 

CR, LF 





No 

CR, 2LF 

CR, 2LF 



Space 3 lines before output. 

Does not matter 

Yes 

CR, 2LF 

CR, 2LF 





No 

CR, 3LF 

CR, 3LF 


+ 

Position to start of current 

Does not matter 

Yes or No 

CR 

CR 



line before output. 






if 

Position to top of form or 

Does not matter 

Yes or No 

EM 

EM 



home cursor before output. 






1 

Position to top of form or 

Does not matter 

Yes or No 

EM, CAN 

EM, CAN 



home cursor and clear screen 







before output; delay 100 







milliseconds before further 







output. 






) 

Do not change position before 

Does not matter 

Yes or No 

None 

None 



output. 
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TABLE 2-2. CCP FORMAT EFFECTOR OPERATIONS FOR ASYNCHRONOUS AND X.25 CONSOLES (Contd) 


Terminal 

Class 

Format 

Effector 

General Physical Operation 

. ■ ....... 

Is Infinite Page 
Length Declared? 

Does Output 
Follow Previous 
Input 

Code Substituted on 
Output Mechanismt 

Display or 
Printer 

Paper Tape 



-..... 1 ----. 

Space 1 line after output. 

Does not matter 

Yes or No 

CR, LF 

CR, LF 







DC3, 







3NUL 


/ 

Position to start of current 

Does not matter 

Yes or No 

CR 

CR, 



line after output. 




DC3, 







3NUL 


Any other 

Space 1 line before output. 

Does not matter 

Yes 

CR 

CR 


ASCII 



No 

CR, LF 

CR, LF 


character 






3 

blank 

Space 1 line before output. 

Does not matter 

Yes 

CR 

CR 





No 

CR, LF 

CR, LF 


0 

Space 2 lines before output. 

Does not matter 

Yes 

CR, LF 

CR, LF 





No 

CR, 2LF 

CR, 2LF 


— 

Space 3 lines before output. 

Does not matter 

Yes 

CR, 2LF 

CR, 2LF 





No 

CR, 3LF 

CR, 3LF 



Position to start of current 

Does not matter 

Yes or No 

CR 

CR 



line before output. 






* 

Position to top of form or 

Does not matter 

Yes or No 

EM 

FF 



home cursor before output. 






1 

Position to top of form or 

Does not matter 

Yes or No 

EM, FF 

FF 



home cursor and clear screen 







before output* 







Do not change position before 

Does not matter 

Yes or No 

None 

None 



output. 







Space 1 line after output. 

Does not matter 

Yes or No 

CR, LF 

CR, LF 







DC3, 







3NUL 


/ 

Position to start of current 

Does not matter 

Yes or No 

CR 

CR, 



line after output. 




DC3, 







3NUL 


Any other 

Space 1 line before output. 

Does not matter 

Yes 

CR 

CR 


ASCII 



No 

CR, LF 

CR, LF 


character 






4tt 

blank 

Space 1 line before output. 

Does not matter 

Yes 

None 

N/A 





No 

NL 



0 

Space 2 lines before output. 

Does not matter 

Yes 

NL 

N/A 





No 

2NL 



_ 

Space 3 lines before output. 

Does not matter 

Yes 

2NL 

N/A 





No 

3NL 



+ 

Position to start of current 

Does not matter 

Yes or No 

nBS 

N/A 



line before output. 



n is calculated by 






TIP from 

current 






position 
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TABLE 2-2. CCP FORMAT EFFECTOR OPERATIONS FOR ASYNCHRONOUS AND X.25 CONSOLES (Contd) 


Terminal 

Class 

Format 

Effector 

General Physical Operation 

Is Infinite Page 
Length Declared? 

Does Output 
Follow Previous 
Input 

Code Substituted on 
Output Mechanismt 

Display or 
Printer 

Paper Tape 


* 

Position to top of form or 

Yes 

Yes 

5NL 

N/A 



home cursor before output. 


No 

6NL 





No 

Yes or No 

nNL 

N/A 






n is calculated by 






TIP from current 






position 



1 

Position to top of form or 

Yes 

Yes 

5NL 

N/A 



home cursor and clear screen 


No 

6NL 




before output. 








No 

Yes or No 

nNL 

N/A 






n is calculated by 






TIP from current 






position 



> 

Do not change position before 

Does not matter 

Yes or No 

None 

None 



output. 






• 

Space 1 line after output. 

Does not matter 

Yes or No 

NL 

NL 


/ 

Position to start of current 

Does not matter 

Yes or No 

nBS 

nBS 



line after output. 



n is calculated by 






TIP from current 






position 



Any other 

Space 1 line before output. 

Does not matter 

Yes 

None 

None 


ASCII 



No 

NL 

NL 


character 






5 

blank 

Space 1 line before output. 

Does not matter 

Yes 

None 

None 





No 

LF 

LF 


0 

Space 2 lines before output. 

Does not matter 

Yes 

LF 

LF 





No 

2LF 

2LF 



Space 3 lines before output. 

Does not matter 

Yes 

2LF 

2LF 





No 

3LF 

3LF 


+ 

Position to start of current 

Does not matter 

Yes or No 

ESC, G 

ESC, G 



line before output. 






* 

Position to top of form or 

Does not matter 

Yes or No 

ESC, H 

ESC, H 



home cursor before output. 






1 

Position to top of form or 

Does not matter 

Yes or No 

ESC, R 

ESC, R 



home cursor and clear screen 







before output. 






> 

Do not change position before 

Does not matter 

Yes or No 

None 

None 



output. 







Space 1 line after output. 

Does not matter 

Yes or No 

LF 

LF, 







DC3, 







3NUL 


/ 

Position to start of current 

Does not matter 

Yes or No 

ESC, G 

ESC, G, 



line after output. 




DC3, 







3NUL 


Any other 

Space 1 line before output. 

Does not matter 

Yes 

None 

None 


ASCII 



No 

LF 

LF 


character 
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TABLE 2-2. CCP FORMAT EFFECTOR OPERATIONS FOR ASYNCHRONOUS AND X.25 CONSOLES (Contd) 


Terminal 

Format 

General Physical Operation 

Is Infinite Page 

Does 

Output 

Previous 

iput 

Code Substituted on 
Output Mechanlsmt 

Class 

Effector 

Length Declared? 


Ii 

Display or 
Printer 

Paper Tape 

6 

blank 

Space 1 line before output. 

Does 

not 

matter 

Yes 

or 

No 

CR 

CR 


0 

Space 2 lines before output. 

Does 

not 

matter 

Yes 



CR 

CR 







No 



2CR 

2CR 


- 

Space 3 lines before output. 

Does 

not 

matter 

Yes 



2CR 

2CR 







No 



3CR 

3CR 


f 

Position to start of current 
line before output. 

Does 

not 

matter 

Yes 

or 

No 

None 

None 


* 

Position to top of form or 
home cursor before output. 

Does 

not 

matter 

Yes 

or 

No 

DC2 

DC2 


1 

Position to top of form or 
home cursor and clear screen 
before output. 

Does 

not 

matter 

Yes 

or 

No 

FS 

FS 


i 

Do not change position before 
output. 

Does 

not 

matter 

Yes 

or 

No 

None 

None 


, 

Space 1 line after output. 

Does 

not 

matter 

Yes 

or 

No 

CR 

CR, 











DC3, 











3NUL 


/ 

Position to start of current 

Does 

not 

matter 

Yes 

or 

No 

None 

DC3, 



line after output. 








3NUL 


Any other 

ASCII 

character 

Space 1 line before output. 

Does 

not 

matter 

Yes 

or 

No 

CR 

CR 

7 

blank 

Space 1 line before output. 

Does 

not 

matter 

Yes 



CR 

CR 







No 



CR,LF 

CR, LF ■ 


0 

Space 2 lines before output. 

Does 

not 

matter 

Yes 



CR, LF 

CR, LF 







No 



CR, 2LF 

CR, 2LF 


- 

Space 3 lines before output. 

Does 

not 

matter 

Yes 



CR, 2LF 

CR, 2LF 







No 



CR, 3LF 

CR, 3LF 


+ 

Position to start of current 
line before output. 

Does 

not 

matter 

Yes 

or 

No 

CR 

CR 


* 

Position to top of form or 
home cursor before output. 

Does 

not 

matter 

Yes 

or 

No 

ESC,[,H 

ESC,[,H 


1 

Position to top of form or 

Does 

not 

matter 

Yes 

or 

No 

ESC,[,H, 

ESC,[,H, 



home cursor and clear screen 
before output. 







ESC,[,J 

ESC,[,J 



Do not change position before 
output. 

Does 

not 

matter 

Yes 

or 

No 

None 

None 


• 

Space 1 line after output. 

Does 

not 

matter 

Yes 

or 

No 

CR, LF 

CR, LF 
DC3, 

3NUL 


/ 

Position to start of current 

Does 

not 

matter 

Yes 

or 

No 

CR 

CR, 



line after output. 








DC3, 

3NUL 


Any other 

Space 1 line before output. 

Does 

not 

matter 

Yes 



CR 

CR 


ASCII 

character 





No 



CR, LF 

CR, LF 


I 
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TABLE 2-2. CCP FORMAT EFFECTOR OPERATIONS FOR ASYNCHRONOUS AND X.25 CONSOLES (Contd) 


Terminal 

Format 

General Physical Operation 

Is Infinite Page 

Does 

Follow 

Output 

Code Substituted on 
Output Mechanismt 

Class 

Effector 

Length Declared? 


Input 

Display or 
Printer 

Paper Tape 

8 

blank 

Space 1 line before output* 

Does 

not 

matter 

Yes 

No 



CR 

CR, LF 

CR 

CR, LF 


0 

Space 2 lines before output. 

Does 

not 

matter 

Yes 

No 



CR, LF 

CR, 2LF 

CR, LF 

CR, 2LF 


- 

Space 3 lines before output. 

Does 

not 

matter 

Yes 

No 



CR, 2LF 
CR, 3LF 

CR. 2LF 
CR, 3LF 


+ 

Position to start of current 
line before output. 

Does 

not 

matter 

Yes 

or 

No 

CR 

CR 


* 

Position to top of form or 
home cursor before output. 

Does 

not 

matter 

Yes 

or 

/ 

No 

ESC, FF 

ESC, FF 


1 

Position to top of form or 
home cursor and clear screen 
before output; delay 1 second 
before further output. 

Does 

not 

matter 

Yes 

or 

No 

ESC, FF 

ESC, FF 


> 

Do not change position before 
output. 

Does 

not 

matter 

Yes 

or 

No 

None 

None 


• 

Space 1 line after output. 

Does 

not 

matter 

Yes 

or 

No 

CR, LF 

CR, LF, 
DC3, 

3NUL 


/ 

Position to start of current 
line after output. 

Does 

not 

matter 

Yes 

or 

No 

CR 

CR, 

DC3, 

3NUL 


Any other 

ASCII 

character 

Space 1 line before output. 

Does 

not 

matter 

Yes 

No 



CR 

CR, LF 

CR 

CR, LF 

tPaper 

tape column 

does not apply to X.25 devices 










ttx.25 devices cannot belong to terminal class 4. 


The application program sets a field in the downline 
block's header word to indicate whether the block 
contains format effectors. ‘ This indication, how¬ 
ever, has no effect on the use of format control 
characters within logical lines of the block. Table 
2-4 lists the code substitutions performed for 
embedded control characters during output to a 
device in each terminal class. This table uses the 
same character representation convention as tables 
2-2 and 2-3, with the following exceptions: the 
hexadecimal terminal codes are shown for multiple 
ASCII character sequences or for non-ASCII character 
sequences. 

Transparent Mode Operation 

Blocks exchanged between an application program and 
a console device in transparent mode do not use most 
of the features of the interactive virtual terminal 
interface: 

No input editing occurs except, by option, the 

Asynchronous, Mode 4, and X.25 TIPs can recog¬ 


nize the user-break-1 and user-break-2 char¬ 
acter codes currently defined for the terminal, 
if entered as the only character in a message 
(see the B1 and B2 commands described in 
section 3). 

No code conversion occurs. 

No format effector transformations are performed 
for downline blocks. 

No page width operations are performed t-o pre¬ 
serve physical line boundaries. 

Page waiting occurs only at the end of a down¬ 
line message. 

Transparent mode operation is separately selected 
for input and output. Either the terminal operator 
or the application program can start transparent 
mode input, using the IN command described in sec¬ 
tion 3. Only the application program can start 
transparent mode output and enable the TIPs to 
recognize the user-break character. 
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TABLE 2-3. CCP FORMAT EFFECTOR OPERATIONS FOR SYNCHRONOUS CONSOLES 


Terminal Class 

j 

Foraat Effector 

General Physical 

Operationt 



Before Outputtt 

After Outputtt 

9 and 14 



0 

Space 1 line. 

Space 

1 

line. 




- 

Space 2 lines. 

Space 

1 

line, 


Any other 

ASCII character§ 

None. 

Space 

1 

line. 

10 thru 13, 15, 



blank 

None. 

Space 

1 

line, 

and 18 











0 

Space 1 line. 

Space 

1 

line. 




- 

Space 2 lines. 

Space 

1 

line. 




+ 

None. 

Space 

1 

line. 




* 

Position to top of form 

Space 

1 

line • 





or home cursor .ttt 







1 

Position to top of form 

Space 

1 

line • 





or home cursor and clear 








screen• 







• 

None. 

space 

1 

line. 




/ 

None. 

Space 

1 

line . 


Any 

other 

ASCII characteri 

None^ 

Space 

1 

line. 

16 and 17 

Any 

ASCII 

character§ 

Before the first line of 

Space 

1 

line. 





the message, generate 








the prefix text 





i 



***C0NS0LE MESSAGE 








Before the subsequent 

Space 

1 

line. 





lines of the message. 








do nothing. 





tNo direct correspondence to code substituted on output device can be made. Code used for 
implementation depends on placement of message blocks within a transmission. 


ttAfter each input and output line, the Terminal Interface Program returns the cursor to the beginning 
(left) margin of the next line. 

tttif these format effectors appear anywhere in a data block other than in the first or last line of the 
data block, the TIP can perform a page-wait operation before the format effector operation. 

§Sent to the terminal. 


Data blocks input in transparent mode have a field 
set in their associated header word to indicate this 
condition. Output blocks require the same field to 
be set. 

Transparent mode data can occupy up to 8 bits of an 
8-bit byte, representing up to 256 distinct char¬ 
acter codes of device instructions. Codes longer 
than 8 bits cannot be exchanged; data packed in 
12-bit bytes by an application program or a termi¬ 
nal device is truncated to 8 bits by the network 
software. 

HASP terminals (terminal classes 9 and 14) and 
bisynchronous terminals (terminal classes 16 and 17) 


cannot transmit or receive such blocks. All other 
terminals can, although mode 4 terminals and 3270 
terminals (terminal classes 10 through 13 and 15) 
require the special treatment described below. 

During transparent mode operation, the application 
program is responsible for all data formatting and 
terminal control. For mode 4 terminals, this means 
that the Terminal Interface Program does not blank- 
fill the current line and unlock the keyboard before 
input can be performed but does add or remove the 
line transmission portion of the protocol envelope 
to or from all message text exchanged with the ter¬ 
minal . 
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TABLE 2-4. EMBEDDED FORMAT CONTROL OPERATIONS FOR CONSOLES 


Terminal Class 

Format Control 
Character 

General Physical Operation 

Code Substituted on Output Mechanism 

1 thru 3 

LF 

Space 1 line before next char- 

LF 

7 and 8 

1 

acter output. 

•cr 


CR 

Position to start of current 
line before next character 
output. 

CR 

4 

i 

LF 

Space 1 line before next char¬ 
acter output. 

LF 


CR 

Position to start of next line 
before next character output. 

NL 

5 

LF 

Space 1 line before next char¬ 
acter output. 

ESC, B 


CR 

Position to start of current 
line before next character 
output. 

ESC, G 

6 

LF 

Space 1 line before next char¬ 
acter output. 

None 


CR 

Position to start of current 
line before next character 
output. 

CR 

9, 14, 

LF 

Space 1 line before next char- 

None 

and 18 

i 

acter output. 



CR 

Position to start of next line 
before next character output. 

None 

10 thru 

j LF 

Space 1 line before next char- 

None 

13 and 


acter output. 


15 

CR 

Position to start of next line 
line before next character 
output. 

IB, 41 (ASCII); 31, 41 (External BCD) 

16 

LF 

Space 1 line before next char¬ 
acter output. 

None 


CR 

Position to start of next line 
before next character output. 

10, IF 

17 

LF 

Space 1 line before next char¬ 
acter output. 

None 


1 CR 

Position to start of next line 
before next character output. 

10, IE 
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3270 Downline Data 


Two mutually exclusive forms of transparent mode 
input can be selected. The network administrator 
can make this selection when the device is defined 
in the network configuration file, or the applica¬ 
tion program or the terminal operator can make it 
while the device is. active. The two forms are: 

Single message 

Multiple message (analogous to block mode 
operation) 

Single-Message Input 

For single-message input, one or more transparent 
mode input delimiters are specified, using the DL 
command options described in section 3. For 
single-message input, when a message ends, trans¬ 
parent mode input ends. Transparent mode messages 
need not be equivalent to normalized mode logical 
1ines. 

Single-message transparent mode input ends when the 
Terminal Interface Program encounters one of the 
mode delimiter conditions. The delimiter condi¬ 
tions are: 

Occurrence of a specific character code in the 
input 

Occurrence of a specific, number of character 
bytes in the input 

Occurrence of a 200- to 400-mllllsecond timeout 
in the input 


M ultiple-Message Input 

For multiple-message input, the application program 
or the terminal user defines one or two input 
message-forwarding signals (equivalent to a normal¬ 
ized mode end-of-line indicator) and one or two 
transparent mode input delimiters. Each message 
ends at a message-forwarding signal; the last mes¬ 
sage ends when transparent input mode ends. The 
message-forwarding signal and mode delimiters may 
be modified as described under Changing Device 
Characteristics in section 3. 

The possible message-forwarding signals are: 

Occurrence of a specific character code in the 
input 

Occurrence of a specific, number of character 
bytes in the input 

The transparent mode delimiters are: 

Two consecutive occurrences of a specific char¬ 
acter code (the message-forwarding signal) 

A sequence of two character codes (a message¬ 
forwarding code followed by a transparent mode 
delimiter code) 

Occurrence of a 200- to 400-ml Hi second timeout 
in the input 


The application constructs a screen-full of 
protected/unprotected fields and supplies all the 
desired attribute characters and screen-buffer- 
addresses for the fields. The TIP is responsible 
for preceding the block of output by SYNC- 
characters, start-of-text, and escape-char, and 
attaches ETX,CRC,PAD at the end. The TIP also 
translates all downline data from ASCII to EBCDIC 
and performs SYNC-fill. 

A typical start of a field would be: 


SBA 

set-buffer-address x'll' 

all in ASCII 

BAl 

buffer-address-1 


BA2 

buffer-address-2 


ATT 

attribute-char 



where the attribute-character determines the char¬ 
acteristics of the field: 

- protected 

- unprotected 

- intensified 

- numeric shift 

The application is also expected to insert the 
cursor at a desired location. 

Once transparent output is delivered to a 3270 
terminal, the TIP assumes transparent input until a 
non-transparent downline block is delivered to the 
terminal. 

To protect the integrity of the protocol, the TIP 
replaces certain downline characters by NULLs. The 
characters replaced are: 

SOH,STX,ETX,EOT,ENQ,ACK,NAK,SYNC 


3270 Upline Data 

Once transparent output is delivered, the TIP sends 
to the host all modified, unprotected fields 
received from the terminal Including the SBA and 
buffer-address-chars (2) of each field. The 
terminal does not send the attribute characters 
back to the TIP. 

If the incoming text is larger than one trans¬ 
mission block (256 characters), the TIP will send 

BLK/BLK/... /MSG 

so that the application can reproduce a full screen. 


Upline Message Blocks 

A transparent mode input block is assembled each 
time the network block size is reached or the Ter¬ 
minal Interface Program encounters a message¬ 
forwarding signal. The last block in the last 
message is assembled when the delimiter condition 
is encountered. If the message-forwarding signal 
is a specific character code, the TIP removes that 
code from the character stream before assembling 
the last block. 
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In transparent mode, the concept of a logical line 
is not meaningful to the network software. Both the 
end-of-line and end-of-block Indicators are data 
within a transparent message. These indicators 
have no significance to the network software. 


Transparent Mode Output 

Transparent mode output data can be divided 
arbitrarily into blocks and messages, provided the 
restrictions on network block size are met. A 
transparent mode downline block ends when the last 
character it contains is transferred to the network 
(defined by the tic field in the block header, 
described later in this section). 

If the TIP is performing page-wait operations for 
the terminal during transparent mode operation, 
output stops to wait for terminal operator acknowl¬ 
edgment at the end of each message. The automatic 
input feature can be used with the last block of a 
transparent mode output message. 


Parity Processing 

Actual terminal codes are right-justified with zero 
fill within the 8-bit character portion of the 
input or output byte. The codes contained in the 
input or output bytes depend on the parity option 
declared for the terminal. 

The actual terminal code parity bit can be used for 
meaningful code only if no parity or Ignore parity 
is declared. Otherwise, the parity bit is zero in 
input blocks and set by the Terminal Interface 
Program on output. 


For example: 

If the terminal uses a 7-blt code such as ASCII, 
with the eighth bit as a parity bit, the set¬ 
ting of the eighth bit is determined by the 
parity option selected for the terminal. If 
zero parity is declared, the eighth bit is 
always zero on input and output. If odd or even 
parity is declared, the eighth bit varies on 
input and output to satisfy the character parity 
requirement. If no parity or Ignore parity is 
declared, the eighth bit is treated as part of 
the character data and is not changed during 
input or output. 

If the terminal uses a 6-blt code, with the 
seventh bit as a parity bit, the setting of the 
seventh bit is determined by the parity option 
selected for the terminal. If zero parity is 
declared, the seventh bit is always zero on 
input and output. If odd or even parity Is 
declared, the seventh bit varies on input and 
output to satisfy the character parity re¬ 
quirement. If no parity or ignore parity is 
declared, the seventh bit is treated as part of 
the character data and is not changed during 
input or output. 


APPLICATION-TO-APPLICATION 
CONNECTION DATA 

Because application-to-applicatlon connection data 
is always exchanged in transparent mode, programs 
can exchange character data in bytes of any size. 
The program at both ends of the connection must 
Interpret the data using the same byte size. 

Programs within the same host can exchange 7-blt or 
8-bit character data in one of three ways: 

Exchange pairs of 60-bit bytes, each containing 
fifteen 8-bit data bytes 

Exchange 8-blt data bytes packed as 8-blt bytes 

Exchange 8-blt data bytes packed within 12-bit 
bytes 

Each of these options corresponds to an application 
character type, as described in the next subsection. 
Programs in different hosts need not use the same 
application character type. 

Programs can exchange 6-bit character data in one 
of two ways: 

If both programs are in the same host, they can 
exchange 60-blt bytes, each containing 6-bit 
(or 6/12-bit) data bytes. 

They can exchange sets of fifteen 8-bit bytes, 
corresponding to two central memory words per 
set (twenty 6-blt characters). 

Figure 2-3 illustrates these possibilities. The 
parity bit (bit 7 of an 8-bit byte) is not altered 
during transmission through the network and can 
always be used as data. 


APPLICATION CHARACTER TYPES 

Blocks always contain character bytes. These char¬ 
acter bytes can be of- several lengths and can be 
packed within bytes of several sizes. Each permit¬ 
ted combination of character byte length and packing 
byte size is called an.application character type. 
There are several application character types sup¬ 
ported by the released version of the software: 

One 60-blt character byte per 60-bit word 

One 8-bit character byte per 8-bit byte 

One 8-blt character byte per 12-bit byte 

One 6-blt display code character byte per 6-bit 
byte 

Blocks transmitted through -a network processing 
unit always consist of 8-blt characters in 8-blt 
bytes. An application program can use blocks of 
this application character type, or have NAM convert 
blocks to or from it so that the application pro¬ 
gram can use one of the remaining valid application 
character types. Block conversion consists of byte 
mapping and character code conversion. 
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7-Bit or 8-Bit Data 



For a downline network data block, NAM: 

Performs no mapping or character code conversion 
on 60-bit character bytes. 

Performs no mapping or character code conversion 
on 8-blt characters in 8-bit bytes; the parity 
setting of the receiving device might cause the 
upper or eighth bit (bit 7) of the byte to be 
set. 

Performs no character code conversion on 12-bit 
bytes but maps the 8-bit character to an 8-bit 
byte by discarding the leftmost four bits of 
the 12; the parity setting of the receiving 
device might cause the upper or eighth bit (bit 
7) of the byte to be set. 


Maps 6-bit characters to 8-blt characters by 
translating the former as 6-blt display ,code 
and substituting the corresponding hexadecimal 
code from the 128-character ASCII set. 


For an upline network data block, NAM: 

Performs no mapping or character code conversion 
on 60-blt character bytes. 

Performs no mapping or character conversion on 
8-blt characters in 8-bit bytes; the parity 
setting of the sending device might cause the 
upper or eighth bit (bit 7) of the byte to be 
set if the data is sent in transparent mode. 
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Performs character mapping but no code conver¬ 
sion by right-justifying 8-bit characters in 
12-blt bytes with zero fill; the parity setting 
of the sending device might cause the upper or 
eighth bit (bit 7) of the byte to be set if the 
data is sent in transparent mode. 

Maps and converts 8-blt characters to 6-blt 
characters by translating all ASCII control 
characters to display coded blanks, and trans¬ 
lating all hexadecimal ASCII character codes 
between 60 and 7F to the display code equiva¬ 
lents of the hexadecimal ASCII character codes 
40 to 5F. All other 7-bit ASCII codes are 
translated to the display codes equivalent to 
the CDC 63-character or 64-character subset of 
the ASCII character set (refer to appendix A). 

Because conversion and mapping between 6-blt and 8- 
blt characters involves a time-consuming character- 
by-character replacement of the block's data, use 
of a 6-blt display coded application character type 
is not recommended and is restricted to blocks 
exchanged with interactive devices. For efficiency, 
8-blt byte characters are recommended for blocks 
exchanged with devices or other application programs 
through the interactive virtual terminal Interface. 

The application character type of an input block is 
determined by the character type associated with 
the logical connection. This association first 
occurs when the connection is established. You can 
change the association as necessary while the con¬ 
nection exists. The application character type of 
a specific input block is always indicated by a 
field in its associated block header word. 

The application character type of an output block 
is determined solely by a field in its associated 
block header area. Input and output, blocks trans¬ 
mitted over the same logical connection can there¬ 
fore have different application character types. 


CHARACTER BYTE CONTENT 

Blocks containing 8-bit characters can be exchanged 
with an interactive device in normalized mode or in 
transparent mode. Blocks exchanged in normalized 
mode always contain 7-blt character codes from the 
ASCII character set, with the eighth bit set to 
zero. Blocks exchanged in transparent mode can 
contain 256 character codes from any character set 
used by a terminal, with the setting of the eighth 
bit determined by the parity processing selected 
for the device. Normalized mode exchanges are the 
initial mode. Blocks exchanged in transparent mode 
are identified by a field in their associated block 
header word. 


Blocks exchanged with another application program 
are always exchanged in transparent mode. Trans¬ 
parent mode is the initial and only exchange mode 
for such connections. Such blocks need not have 
•transparent mode use identified by a field in their 
associated block header word. 


The legal combinations of character types, modes, 
and uses are summarized in table 2-5, The mecha¬ 
nisms for declaring character types and exchange 
modes are described in the Block Header Content 
portion of this section and in section 3. 


BLOCK HEADER CONTENT 

The content of the block header word associated 
with a data block depends on whether the application 
program is sending or receiving the block. The 
requirements for all header words associated with 
upline data blocks are described in figure 2-4. 
The requirements for all header words associated 
with downline data blocks are described in 
figure 2-5. 

SUPERVISORY MESSAGE CONTENT 
AND SEQUENCE PROTOCOLS 

Supervisory message blocks consist of 1 to 410 60- 
bit words or 1 to 2043 12-blC bytes. The fields 
within these blocks convey information and instruc¬ 
tions to the network software, in a manner similar 
to the character bytes of a data message block. 
Supervisory messages are sent and received through 
the same application program routines as are used 
for data blocks. (See sections 4 and 5.) Supervi¬ 
sory messages have associated block header words, 
just as data blocks do. These header words convey 
information to the network software concerning the 
contents of the corresponding text area buffer. 

Supervisory messages have the general formats shown 
in figures 2-6 and 2-7. A specific message contains 
a fixed combination of four fields and can Include 
additional parameters. The individual messages 
supported by the network software are described in 
section 3. The fields are described below in the 
order of their use, rather than in the order of 
their occurrence within a supervisory message. 

The first of the four fields common to all supervi¬ 
sory messages is the primary function code. The 
primary function code is used to group supervisory 
messages into related functions and determine their 
routing within the network software. 

Functions routed between NAM and the application 
program are represented in figures 2-6 and 2-7 by 
mnemonics. These mnemonics are defined in paren¬ 
theses after the corresponding function in the 
following list: 

Connection data flow control (FC) 

Error reporting (ERR) 

Device control (CTRL) 

Connection list management (LST) 

Connection characteristic definition (DC) 
Interrupt request (INTR) 

Connection control (CON) 

Terminal characteristic definition (TCH) 

Network shutdown (SHUT) 

Host operator commands (HOP) 

Terminate output (TO) 

Break Indication (BI) 

Resume output (RO) 
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TABLE 2-5. CHARACTER EXCHANGES WITH CONNECTIONS 


Application 
Character Type 

ACT Field 
Value 

Exchange Mode 
Used 

Connection 

Type 

Code Set 
(Character Set) 

60-blt characters 

In 60-blt bytes 

1 

Transparent 

Appliestion-to-application 
vd.thln the same host 

Binary (None) 

8-blt characters 
in 8-blt byte 

2 

No nnalized 

Application-to-device 

(consoles) 

7-blt ASCII (128 ASCII) 

8-blt characters 
in 8-bit bytes 

2 

Transparent 

Application-to-device 

(consoles) 

Any 6-, 7-, or 8-blt 
(Unknown) 

8-bit characters 
in 8-blt bytes 

2 

Transparent 

Ap piic a tion-1 o-a pplica tion 

Binary (None) 

8-bit characters 
in 12-bit bytes 

3 

Normalized 

Application-to-device 

(consoles) 

7-blt ASCII (128 ASCII) 

8-bit characters 
in 12-bit bytes 

3 

Transparent 

Application-to-device 

(consoles) 

Any 6-, 7-, or 8-bit 
(Unknown) 

8-bit characters 
in 12-bit bytes 

3 

Transparent 

Appllcatlon-to-application 

Binary (None) 

6-bit characters 
in 6-bit bytes 

4 

Normalized 

Appllcatlon-to-device 

(consoles) 

6- bit display code to/from 

7- bit ASCII (64-character 
subset of ASCII) 
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ha Symbolic header area address, specified as the location to receive the application block 

header in a call to NETGET, NETGETL, NETGETF, or NETGTFL (see section 5). 

abt Application block type of the associated network data block. This field can have the 

values: 

=0 indicates a null block. (No block is queued or none can be delivered from 

the logical connection polled.) 

=1 indicates that the associated block is one of several blocks comprising a 

single message, but is not the last such block. 

=2 indicates that the associated block is either the last or only one 

comprising the message. 

=6 indicates that the associated block is one of several blocks comprising a 

single qualified data message, but is not the last such block. 

=7 indicates that the associated block is either the last or only one 

comprising a qualified data message. 

Values of 3 through 5 and 8 through 63 are not valid for data blocks on input. You can 
access this field with the reserved symbol ABHABT (see section 4). 

acn Application connection number of the logical connection from which the associated block 

was sent. This field can have the values 1 £ minacn ^ acn _< maxacn ^ 4095, where the 
values minacn and maxacn are parameters in the NETON statement (see section 5). You can 
access this field with the reserved symbol ABHADR (see section 4). 


Figure 2-4. Application Block Header Content for Upline Network Data Blocks (Sheet 1 of 4) 
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act 


Application character type used to encode the accompanying block. This field can contain 
the values: 

=1 60-bit transparent characters, packed one per central memory word; this 

character type can be used only for application-to-application connections 
within the same host. 

=2 8-bit characters, packed 7.5 per central memory, word; this character type 

is recommended for transparent mode or normalized mode data on device-to- 
application connections and for application-to-applicat ion connections 
between hosts. 

=3 8-bit characters, right-justified in 12-bit bytes with zero fill, packed 5 

per central memory word; this character type can be used for transparent 
mode or normalized mode data on device-to-applicat ion connections and for 
application-to-appLication connections. 

=4 6-bit display code characters (see table A-1 in appendix A), packed 10 per 

central memory word. This value can be used only for device-to-application 
connections in normalized mode when the block is exchanged with a site- 
defined device or a COC-defined console device. 

=5 thru Reserved for CDC use; not currently recognized. 

11 


=12 Reserved for installation use; usage and content are unrestricted and 

thru 15 undefined (the released version of the software does not recognize these 
values). 

The value contained in the act field is the value assigned to the connection by the 
application program for input, either in the connection-accepted supervisory message Cict 
field) or in the most recent change-input-character-type supervisory message (see section 
3). You can access this field with the reserved symbol ABHACT (see section 4). 

ibu Input-block-undeliverable bit. When ibu has a value of 1, the block associated with 

this block header has not been delivered to the application program; ibu is 1 when the 
block: 


Is larger than the maximum text length (tlmax parameter) declared by the application 
program in its NETGET, NETGETL, NETGETF, or NETGTFL call and the program has not 
requested that input data be truncated (see the truncate-input asynchronous 
supervisory message described in section 3). The block header contains the actual 
length of the queued block in its tic field, given in character units specified by 
the act field. The block remains queued until the application program takes one 
of the following actions: 

Uses the change-input-character-type asynchronous supervisory message 
described in section 3 to compress the characters into fewer central memory 
words by using a different application character type to pack them more 
densely. 

Uses the input-truncation asynchronous supervisory message described in 
section 3 to delete enough characters so that the remainder fit into the 
existing text area. 

Uses a longer text area. 

The application program then must use another NETGET, NETGETL, NETGETF, or NETGTFL 
call to obtain the block. 


Figure 2-4. Application Block Header Content for Upline Network Data Blocks (Sheet 2 of 4) 
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res 

tru 


xpt 


f 


• Contains transparent node data from a connection using an act value of 4. The 
block header contains the actual length of the queued block in its tic field 
(given in 8-bit bytes) and has an xpt value of 1 (see xpt field description). 

The application program can: 

Change the input character type for the connection to a value of 2 or 3, 
using the change-input-character-type asynchronous supervisory message 
described in section 3, then use a NETGET, NETGETL, NETGETF, or NETGTFL 
call to obtain the block. 

Use the change-input-character-type asynchronous supervisory message with a 
set nxp bit as described in section 3; this discards the queued block and 
all subsequent blocks of transparent data from the connection. 

• Is queued on a connection between application programs within the same host and the 
act value specified by your application does not match the act value specified by 
the other application in its NETPUT call for the block. The application program can: 

Change the input character type for the connection using the change-input- 
character-type asynchronous supervisory message described in section 3, 
then use a NETGET, NETGETL, NETGETF, or NETGTFL call to obtain the block. 

You can access this field with the reserved symbol ABHIBU (see section 4). 

Reserved for CDC use. 


Truncated data bit. When tru is 1, the block associated with this block header has been 
truncated to fit into the text area used. When tru is 0, the block has not been 
truncated. The tru bit cannot be 1 unless the application program has issued the data 
truncation control asynchronous supervisory message described in section 3 and that 
message affects transmissions on this connection. When truncation occurs, the tic field 
contains the maximum number of complete transferred character bytes of the block. You can 
access the tru field with the reserved symbol ABHTRU (see section 4). 

Transparent mode bit, indicating whether the accompanying block contains transparent mode 
data. If your program chooses not to receive transparent mode input when it accepts a 
connection or changes the input character type of the connection (nxp field, described in 
section 3), an xpt value of 1 is received in a block with an abt of 0 (an empty block) 
and indicates that one or more transparent mode blocks were discarded by the network 
software. 


If your program can receive transparent mode input, the interpretation of the value this 
field contains depends on the act value used, as follows: 

act=1, xpt should be ignored. 

act=2, if the data is from a site-defined device or a CDC-defined console device: 


xpt=0 indicates normalized mode data for which interactive virtual terminal 
transformations were performed; 7-bit characters are from the 
128-character ASCII set (see appendix A). 


xpt=1 indicates transparent mode data for which no transformations were 
performed; all eight bit positions might be used to form 256 
characters, but the application program must correctly interpret the 
format of such data. 


act=2, • if the data is from an application program: 


xpt=0 indicates that the sending application program did not use an xpt 
value of 1 in its block header for the accompanying block. 

xpt=1 indicates that the sending application program used an xpt value of 
1 in its block header for the accompanying block. 


Figure 2-4. Application Block Header Content for Upline Network Data Blocks (Sheet 3 of 4) 
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act=3 


if the data is from a site-defined device or a CDC-defined console device: 


xpt=0 indicates normalized mode data for which interactive virtual terminal 
transformations were performed; 7-bit characters are from the 
128-character ASCII set (see appendix A). 

xpt=1 indicates transparent mode data for which no transformations were 
performed; all eight bit positions in the character portion of the 
character byte might be used to form 256 characters, but the 
application program, must correctly interpret the format of such data. 

act=3, if the data is from an application program: 

xpt=0 indicates that the sending application program! did not use an xpt 
value of 1 in its block header for the accompanying block. 

xpt=1 indicates that the sending application program! used an xpt value of 
1 in its block header for the accompanying block. 

act=4, if the data is from a site-defined device or a CDC-defined console device: 

xpt=0 indicates normalized mode data for which interactive virtual terminal 
transformations were performed; 6-bit characters are from the 6-bit 
display code set (see table A-1 in appendix A). 

xpt=1 indicates that the ibu bit is also set; the tic field contains the 
actual block length in 8-bit characters (not in 6-bit characters). 
Transparent mode is not supported for act=4; a change-input- 
character-type supervisory message must be issued before the block 
can be received (see section 3). 

You can access this field with the reserved symbol ABHXPT (see section 4). 

can Cancel-input bit. When- can is 1, the terminal operator used the cancel-input key 

defined for the device or the break condition key (see BR command in section 3) to end the 
text in the associated block. The associated block always has an abt of 2, and the data 
is always from a console device. The cancel-input request also applies to any blocks with 
an abt value of 1 that preceded this block; all blocks in the same message should be 
discarded. You can access this field with the reserved symbol ABHCAN (see section 4). 

pef Parity error flag bit. When pef is 1, the associated block contains a parity error in 

one or more of its characters. You can access this field with the reserved symbol ABHBIT 
(see section 4). 

tic Text length of the associated block, in character units specified by the act field. The 

equivalent length in central memory words can be computed as follows: 


act=1, tic is the number of central memory words the block requires. 


act=2. 

the number of central memory words 
7.5, rounded upward to an integer. 

the 

block requires 

-is 

tic 

divided by 

act=3. 

the number of central memory words 
5, rounded upward to an integer. 

the 

block requires 

is 

tic 

divided by 

act=4. 

the number of central memory words 

the 

block requires 

is 

tic 

divided by 


10, rounded upward to an integer. 


act=5 tic is undefined. 

thru 

15 

You can access this field with the reserved symbol ABHTLC (see section 4). 


!The xpt value will always be set to 0 in the upline network block if the data passes through a 
packet switching network. Therefore, to get consistent results, it is strongly suggested that xpt=0 
be used on all application-to-application connections. 


Figure 2-4. Application Block-Header Content for Upline Network Data Blocks (Sheet 4 of 4) 
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ha SyraboLic header area address, specified as the application block header's location in a 

call to NETPUT or NETPUTF (see section 5). 


abt Application block type of the accompanying network data block. This field can contain the 

values; 

=1, indicates that the accompanying block is one of several blocks comprising a 

single message, but is not the last such block. 

=2, indicates that the accompanying block is either the last or only one 

comprising a message. 

=6 indicates that the associated block is one of several blocks comprising a 

single qualified data message, but is not the last such block. 

=7 indicates that the associated block is either the last or only one 

comprising a qualified data message. 

Values of 0, 3 through 5, and 8 through 53 are not valid for data blocks on output. You 
can access this field with the reserved symbol ABHABT (see section 4). 

acn Application connection number of the logical connection to which the accompanying block 

should be sent. This field can contain the values 1 £ rainacn £ acn £ maxacn £ 4095, where 
the values minacn and maxacn are parameters in the NETON statement (see section 5.) You 
can access this field with the reserved symbol ABHADR (see section 4). 

abn Application block number assigned to the block being sent. This field is an 18-bit 

integer that identifies the block when the network software's processing of the block 
returns certain supervisory messages (see section 3). You define the block number; it can 
be: 

A sequencing number 

The block's central memory address 

The block's mass storage address (physical record unit) 


An index value for a block control array or table 

An external label 

You can access this field with the reserved symbol ABHABN (see section 4). 

act Application character type used to encode the accompanying block. This field can contain 

the values: 

=1, 60-bit transparent characters, packed one per central memory word; this 

character type can be used only for application-to-application connections 
within the same host. 

=2, 8-bit characters, packed 7.5 per central memory word; this character type 

is recommended for transparent mode data or normalized mode data on 
device-to application connections or for application-to application 
connections between hosts. 

=3, 8-bit characters, right-justified in 12-bit bytes, packed 5 per central 

memory word; this character type can be used for transparent mode or 
normalized mode data on device-to-application connections, or for 
application-to-application connections. 


Figure 2-5. Application Block Header Content for Downline Network Data Blocks (Sheet 1 of 3) 
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II 

\ 

6-bit display code characters (see table A-1 in appendix A), packed 10 per 
central memory word. This value can be used only for normalized mode data 
on application-to-terminal connections when the block is exchanged with a 
site-defined device or a CDC-defined console device. 


=5 thru 

11 

Reserved for CDC use; not currently recognized. 


=12 

thru 15 

Reserved for installation use; usage and content are unrestricted and 
undefined (the released version of the software does not recognize these 
values). 


You can access 

this field with the reserved symbol ABHACT (see section 4). 

ncp 

No-cursor-positioning bit, indicating whether cursor positioning is to be disabled for the 
input operation that immediately follows this output block. If ncp is 1, no cursor 
positioning is to be performed for the next input operation; if ncp is 0, cursor 
positioning can be performed for the next operation. This bit is ignored for blocks sent 
on application-to-application connections and for blocks with an abt of 1 on 
device-to-application connections. You can access this field with the reserved symbol 

A8HNCP (see section 4). 

nfe 

No-format-effector bit, indicating whether the accompanying block contains format 
effectors. If nfe is 1, there are no format effectors in the block; if nfe is 0, the 
block contains format effectors requiring removal and interpretation. The nfe field 
applies only to normalized mode data exchanged with a site-defined device or a CDC-defined 
console device. You can access this field with the reserved symbol ABHHFE (see section 4). 

xpt 

Transparent mode bit, indicating whether the accompanying block contains transparent mode 
data. The value used in this field depends on the act value used, as follows: 


act=1. 

xpt value does not determine data translation and can be 1 or 0. A value 
of 0 is recommended. 


act=2. 

if the data is for a site-defined device or a CDC-defined console device: 



xpt=0 indicates normalized mode data for which interactive virtual terminal 
transformations should be performed; 7-bit characters are from the 
123-character ASCII set (see appendix A). 



xpt=1 indicates transparent mode data for which no transformations are to 
be performed; all eight bit positions can be used to form 256 
characters (if parity of none is used), but such data must be 
correctly formatted for terminal output. 


act=2. 

if the data is for an application program, -xpt does not affect data 
translation and can be 1 or 0. For data passing through a public data 
network, the receiving application will always see xpt=0. Therefore, it 
is strongly recommended that a value of xpt=0 be used by the sender. 


act=3. 

if the data is for a site-defined device or a CDC-defined console device: 



xpt=0 indicates normalized mode data for which interactive virtual terminal 
transformations should be performed; 7-bit characters are from the 
128-character ASCII set (see appendix A). 



xpt=1 indicates transparent mode data for which no transformations are 

performed; all eight bit positions in the character portion of the 
character byte can be used to form 256 characters (if parity of none 
is used), but such data must be correctly formatted for terminal 
output. 


act=3. 

if the data is for an application program, xpt does not affect data 
translation and can be 1 or 0. For data passing through a public data 
network, the receiving application will always see xpt=0. Therefore, it 
is strongly recommended that a value of xpt=0 be used by the sender. 


act=4. 

xpt value does not determine data translation and can be 1 or 0. A value 
of 0 is recommended. 


Figure 2-5. Application Block Header Content for Downline Network Data Blocks (Sheet 2 of 3) 
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act= 

other 


xpt is not defined 


You can access this field with the reserved symbol ABHXPT (see section 4). 


nep 


res 

tic 


No-echoplexing bit, indicating whether the next logical line of nontransparent input data 
should not be echoplexed. If nep is 1 and the NPU is echoing characters back to the 
terminal CY value of EP command, described in NAH Version 1/CCP Version 3 Terminal 
Interfaces reference manual), the NPU does not echo the next logical line from the 
console. If nep is 0 and the NPU is echoing characters (Y value of EP command), the NPU 
does echo the next logical line of input. This bit is ignored for blocks sent on 
application-to-application connections and for blocks with an abt of 1 on 
device-to-application connections. You can access this field with the reserved symbol 
ABHNEP (see section 4). 

Reserved for CDC use. Reserved fields contain zero. 


Text length of the associated block, in character units specified by the act value. The 
value to use in the tic field can be computed as follows: 


act=1, tic is the number of central memory words occupied by the block. 

act=2, tic is the number of complete central memory words occupied by the block 

times 7.5, plus the number of complete character bytes used in any 
remaining central memory word, rounded upward to an integer. 

act=3, tic is the number of complete central memory words occupied by the block 

times 5, plus the number of 12-bit character bytes used in any remaining 

central memory word. 

act=4, tic is the number of complete central memory words occupied by the block 
times 10. 


act=5 tic is not defined, 
thru 15 

The character count used as the text length must include any format effectors and 
end-of-line indicator bytes contained in the block. You can access this field with the 
reserved symbol ABHTLC (see section 4). 


Figure 2-5. Application Block Header Content for Downline Network Data Slocks (Sheet 3 of 3) 


The precise function of a message within a primary 
function grouping is indicated by its secondary 
function code, forming the fourth common field. The 
mnemonic symbols used to identify these secondary 
function codes are related to the use of Che mes¬ 
sages. Mnemonics for these codes also appear in 
figures 2-6 and 2-7 and in parentheses after the 
secondary functions in the following list: 


Request for logical connection (REQ) 

End of connection (END) 

Connection broken (CB) 

Appllcatlon-to-applicatlon connection request 
(ACRQ) 

Internal shutdown (INSD) 

Inactive connection (INACT) 

No acknowledgment (NAK) 

Acknowledgment (ACK) 


Reset (RST) 

Break (BRK) 

Logical problem (LGL) 

Initialization (INIT) 

Mark point in data (MARK) 

Switch connection between lists (SUH) 

Turn connection list processing off (OFF) 

Turn connection list processing on (ON) 

Turn half-duplex operation on for connection on 
a list (HDX) 

Turn full-duplex operation on for connection on 
a list (FDX) 

Begin truncating input on a connection (TRU) 
Application interrupt request (APP) 

User interrupt.request (USR) 


2-32 


60491500 W 




Interrupt response (RSP) 

Change Input character type (CICT) 

Report of changed terminal characteristics 
(TCHAR) 

Request terminal characteristics (RTC) 


Define single terminal characteristic (DBF) 

Define multiple terminal characteristics (TCD) 

Downline CCP terminal multiple characteristics 
definition (CHAR) 

Define CDCNET terminal characteristics (CTD) 



ta Symbolic text area address, specified in a NETGET, NETGETF, NETGETL, or NETGTFL call as 

the location to receive an upline supervisory message or specified in a NETPUT or NETPUTF 
call as the location from which to send a downline supervisory message (see section 5). 

pfc Primary function code. Field mnemonics are used throughout this manual in specific 

message formats. Reserved symbols corresponding to the field mnemonics can be used to 
access message fields (see section 4). Reserved symbols for the primary function code are 
used throughout this manual within mnemonics identifying specific messages. The mnemonics 
and their unpacked (right-justified) numerical equivalents are: 


Field Mnemonic 

Reserved 

Symbolic Mmemonic 

Octal 

Hexadecimal 

Decimal 

bit 

BI 

312 

CA 

202 

con 

CON 

143 

63 

099 

ctrlt 

CTRL 

301 

Cl 

193 

dc 

DC 

302 

C2 

194 

err 

ERR 

204 

84 

132 

fc 

FC 

203 

83 

131 

hop 

HOP 

320 

DO 

208 

intr 

INTR 

200 

80 

128 

1st 

LST 

300 

CO 

192 

rot 

RO 

313 

CB 

203 

shut 

SHUT 

102 

42 

066 

tch 

TCH 

144 

64 

100 

tot 

TO 

304 

C4 

196 

Primary function 

codes 00 through EO hexadecimal are reserved for CDC use. 

Hexadecimal 

codes El through 

EF are for installation use 

and have no predefined meanings or reserved 

symbols. You can 

access the pfc field with 

the reserved 

symbol PFC (see 

section 4). 


eb Error bit. When set to 1, eb indicates the occurrence of- an error (an abnormal response 

to a previous supervisory message); when set to 0, eb indicates a normal response. The 
eb field always contains 0 when a supervisory message is not a response to a prior 
message. You can access this field with the reserved symbol E8 (see section 4). 

rb Response bit. When set to 1, rb indicates a normal response to a previous supervisory 

message; rb is always 0 in a supervisory message that is not a response to a previous 
message. You can access this field with the reserved symbol RB (see section 4). 

sfc Secondary function code. Field mnemonics are used throughout this manual in specific 

message formats. Reserved symbols corresponding to the field mnemonics can be used to 
access message fields (see section 4). Reserved symbols for the secondary function code 
are used throughout this manual within mnemonics identifying specific messages. The sfc 
mmemonics and their unpacked (right-justified) numerical equivalents are: 


Figure 2-6. Supervisory Message General Content, Asynchronous Messages 
and Synchronous Messages of Application Character Type 2 (Sheet 1 of 2) 
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Related 

Reserved 




Field Mnemonic 

Symbolic pfc 

Symbolic Mnemonic 

Octal 

Hexadecima 1 

Decimal 

req 

CON 

REQ 

00 

00 

00 

acrq 

CON 

ACRQ 

02 

02 

02 

cb 

CON 

CB 

05 

05 

05 

end 

CON 

END 

06 

06 

06 

ccdt 

CTRL 

CCD 

14 

OC 

12 

ctdt 

CTRL 

CTD 

02 

02 

02 

deft 

CTRL 

DEF 

04 

04 

04 

chart 

CTRL 

CHAR 

10 

08 

08 

rcct 

CTRL 

RCC 

13 

oe 

11 

rtct 

CTRL 

RTC 

11 

09 

09 

tcdt 

CTRL 

TCD 

12 

OA 

10 

ci ct 

DC 

CICT 

00 

00 

00 

stmr 

DC 

STMR 

02 

02 

02 

tru 

DC 

TRU 

01 

01 

01 

LgL 

ERR 

LGL 

01 

01 

01 

brk 

FC 

BRK 

00 

00 

00 

rst 

FC 

RST 

01 

01 

01 

ack 

FC 

ACK 

02 

02 

02 

nak 

FC 

NAK 

03 

03 

03 

inact 

FC 

INACT 

04 

04 

04 

init 

FC 

INIT 

07 

07 

07 

brk 

HOP 

BRK 

00 

00 

00 

cmd 

HOP 

CMD 

01 

01 

01 

trace 

HOP 

TRACE 

02 

02 

02 

du 

HOP 

DU 

03 

03 

03 

ig 

HOP 

IG 

04 

04 

04 

start 

HOP 

START 

05 

05 

05 

endd 

HOP 

ENDD 

06 

06 

06 

notr 

HOP 

NOTR 

07 

07 

07 

rs 

HOP 

RS 

10 

08 

08 

dis 

HOP 

DIS 

11 

09 

09 

ig 

HOP 

LG 

12 

OA 

10 

alt 

HOP 

ALT 

13 

QB 

11 

page 

HOP 

PAGE 

14 

OC 

12 

rel 

HOP 

REL 

15 

OD 

13 

db 

HOP 

DB 

16 

OE 

14 

de 

HOP 

DE 

17 

OF 

15 

day 

HOP 

DAY 

20 

10 

16 

usr 

INTR 

USR 

00 

00 

00 

rsp 

INTR 

RSP 

01 

01 

01 

app 

INTR 

APP 

02 

02 

02 

off 

LST 

OFF 

00 

00 

00 

on 

LST 

ON 

01 

01 

01 

swh 

LST 

SWH 

02 

02 

02 

f dx 

LST 

FDX 

03 

03 

03 

hdx 

LST 

HDX 

04 

04 

04 

i nsd 

SHUT 

INSD 

06 

06 

06 

tchar 

TCH 

TCHAR 

00 

00 

00 

markt 

TO or 

BI or 

RO 

MARK 

00 

00 

00 

You can access 

the sfc field 

with the reserved 

symbol SFC 

(see section 

4). 


parameters These parameters can extend into words 2 through n; n £ 410. Parameters are defined in 
the descriptions of the specific messages in section 3. 


tsynchronous supervisory message fields. 


Figure 2-6. Supervisory Message General Content, Asynchronous Messages 
and Synchronous Messages of Application Character Type 2 (Sheet 2 of 2) 
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ta Symbolic text area address, specified in a NETGET, NETGETF, NETGETL, or NETGTFL call as the 

location to receive an upline supervisory message or specified in a NETPUT or NETPUTF call 
as the location from which to send a downline supervisory message (see section 5). 

pfc Primary function code. Field mnemonics are used throughout this manual in specific message 

formats. Reserved symbols corresponding to the field mnemonics can be used to access 
message fields (see section 4). Reserved symbols for the primary function code are used 
throughout this manual within mnemonics identifying specific messages. The mnemonics and 
their unpacked (right-justified) numerical equivalents are: 

Reserved 

Field Mnemonic Symbolic Hmemonic Octal H exadecimal Decimal 

bi BI 312 CA 202 

Ctrl CTRL 301 Cl 193 

ro RO 313 CB 203 

to TO 304 C4 196 

Primary function codes 00 through EO hexadecimal are reserved for CDC use. Hexadecimal 
codes El through EF are for installation use and have no predefined meanings or reserved 
symbols. You can access the pfc field with the reserved symbol PFC (see section 4). 

eb Error bit. When set to 1, eb indicates the occurrence of an error (an abnormal response 

to a previous supervisory message); when set to 0, eb indicates a normal response. The 
eb field always contains 0 when a supervisory message is .not a response to a prior 
message. You can access this field with the reserved symbol EB (see section 4). 

rb Response bit. When set to 1, rb indicates a normal response to a previous supervisory 

message; rb is always 0 in a supervisory message that is not a response to a previous 
message. You can access this field with the reserved symbol R3 (see section 4). 

sfc Secondary function code. Field mnemonics are used throughout this manual in specific 

message formats. Reserved symbols corresponding to the field mnemonics can be used to 
access message fields (see section 4). Reserved symbols for the secondary function code 
are used throughout this manual within mnemonics identifying specific messages. The sfc 
mmemonics and their unpacked (right-justified) numerical equivalents are: 

Related Reserved 


Field Mnemonic 

Symbolic pfc 

Symbolic Mnemonic 

Octal 

Hexadecimal 

Decimal 

ctd 

CTRL 

CTD 

02 

02 

02 

def 

CTRL 

DEF 

04 

04 

04 

char 

CTRL 

CHAR 

10 

08 

08 

rtc 

CTRL 

RTC 

11 

09 

09 

ted 

CTRL 

TCD 

12 

OA 

10 

mark 

TO or 

MARK 

00 

00 

00 


BI or 






RO 






You can access the sfc field with the reserved symbol SFC (see section 4). 

parameters These parameters can-extend into words 2 through n; n < 410. Parameters are defined in 
the descriptions of the specific messages in section 3. 


Figure 2-7. Supervisory Message General Content, Synchronous 
Messages of Application Character Type 3 
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The second and third common fields are used to 
indicate whether the function was performed or not. 
By convention, these fields are called the error 
and response bits. The error bit is usually set to 
indicate the message recipient's refusal to perform 
the function; the response bit is set to indicate 
the recipient's normal completion of the function. 

Together, the four common fields define one super¬ 
visory message. Supervisory messages can be grouped 
into two classes of sequencing protocol: 

Asynchronous (the largest class) 

Synchronous 


ASYNCHRONOUS MESSAGES 

Asynchronous supervisory messages are sent or 
received separately from the stream of data message 
blocks between an application program and a logical 
connection. Their receipt or the need to send them 
cannot be predicted from the generalized logic 
required for data block processing. Such messages 
are said to be asynchronous to the data block 
stream. 

All asynchronous messages are sent or received on a 
special logical connection with the preassigned 
application connection number of zero. The network 
software preassigns this application connection 
number to connection list zero. 

All asynchronous supervisory messages are actually 
sent to or received from software resident in the 
host computer, although they may be reformatted by 
this software for communication with software out¬ 
side of the host. These messages conform to the 
requirements of applicatlon-to-appllcation connec¬ 
tions. Asynchronous supervisory messages therefore 
use an application character type of one. All 
supervisory messages are assigned the nonzero 
application block type of three. 

Asynchronous supervisory messages are processed 
with the same AIP routines used by an application 
program to process data message blocks on logical 
connections other than application connection number 
zero. Asynchronous supervisory messages are queued 
on their special connection until fetched by the 
application program. 

The application program fetches supervisory messages 
one message at a time. When the connection queue 
is empty, a null block with an application block 
type of zero is returned. 

The network software provides a mechanism for the 
application program to determine when asynchronous 
supervisory messages are queued on application con¬ 
nection number zero. When a call to an AIP routine 
is completed, a supervisory status word at a loca¬ 
tion defined by the application program is updated 
to indicate whether any asynchronous supervisory 
messages are queued. As long as the application 
program continues to make calls to AIP routines, it 
can test the supervisory status word periodically 
(Instead of attempting to fetch null blocks from 
application connection number zero). The supervi¬ 
sory status word and the use of NETWAIT are 
described in section 5. 


SYNCHRONOUS MESSAGES 

Synchronous supervisory messages are sent or 
received embedded in the stream of data message 
blocks between an application program and a logical 
connection. Their receipt or the need to send them 
is determined by the generalized logic required for 
data block processing. Such messages are said to 
be synchronous with the data block stream. 

All synchronous messages are sent or received on 
the logical connection to which they apply. This 
logical connection cannot be application connection 
number zero. 


All synchronous supervisory messages are actually 
sent to or received from network software outside 
of the host computer. Because the application pro¬ 
gram processes these messages as network blocks 
sent to or received from terminals, the messages 
conform to the requirements of appllcatlon-to- 
terminal connections. Synchronous supervisory mes¬ 
sages use an application character type of two or 
three; your program specifies which is used when it 
accepts the connection to the terminal. 

Synchronous supervisory messages are processed with 
the same AIP routines used by an application pro¬ 
gram to process other blocks on logical connections. 
Synchronous supervisory messages are queued on 
their connections until fetched by the application 
program. Because the application program must dis¬ 
tinguish between data or null blocks and synchronous 
supervisory message blocks, supervisory messages 
are assigned the application block type of three. 


The network software provides a mechanism for the 
application program to determine when synchronous 
supervisory messages or data blocks are queued on a 
logical connection. When a call to the AIP routine 
NETWAIT is completed, a supervisory status word at 
a location defined by the application program is 
updated to Indicate whether any synchronous super¬ 
visory message or data blocks are queued. The 
application program can test the supervisory status 
word periodically, Instead of attempting to fetch 
null blocks from all application connection num¬ 
bers. The supervisory status word and the use of 
NETWAIT are described in section 5. 


Synchronous supervisory messages are subject to the 
same application block limit as data messages and 
are similarly acknowledged. This process is 
described in section 3. 


BLOCK HEADER CONTENT 

The content of the block header word associated 
with a supervisory message depends on whether the 
message is asynchronous or synchronous, and on 
whether it is being sent or received. The require¬ 
ments for asynchronous and synchronous messages are 
described in the preceding subsection. The 
requirements for all header words associated with 
Incoming supervisory messages are described in 
figure 2-8. The requirements for all header words 
associated with outgoing supervisory messages are 
described in figure 2-9. 
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ha Symbolic header area address, soecified as the location to receive the application block 

header in a call to NETGET, NETGETF, NETGETL, or NETGTFL (see section 51. 

abt Application block type of the associated message block. This field can contain the values: 

=0, indicates a null block. (No message is queued or can be delivered from the 

logical connection polled.! 

=5, indicates that the accompanying block is a supervisory message block. 

Values of 1, and 4 through 43 are not valid for supervisory messages on input. You can 
access this field with the reserved symbol A8HA0T (see section 41. 

adr Application connection number of the logical connection from which the message block 

comes. This field can have the values: 

=n, for asynchronous supervisory messages from the host portion of the network 

software. 

=acn, for synchronous supervisory messages from the Terminal Interface Program 
servicing the logical connection with the indicated nonzero application 
connection number. 

You can access this field with the reserved symbol ABHADR (see section 41. 

act Application character type used to encode the accompanying message block. The value 

appearing in this field depends on the type of supervisory message involved and on the 
act value you chose (the set field described in section 3) for synchronous supervisory 
messages on this connection; this field can contain the values: 

=1, an asynchronous supervisory message packed in 6n-bit words, must be used 

for supervisory messages with an adr value of 0. 

=2, a synchronous supervisory message packed in 8-bit characters, T,5 

characters per central memory word (the recommended valuel. 

=3, a synchronous supervisory message packed in S-bit characters, 5 characters 

per central memory word. 

Because the fields within supervisory messages are groups of bits within central memory 
words (rather than characters in a character strinql, the act field of a supervisory 
message does not indicate that character mapping occurred. You can access this field with 
the reserved symbol ABHACT (see section 41. 

ibu Input-block-undeliverable bit. When ibu is 1, the block associated with this block 

header has not been delivered to the application program. The block is larger than the 
maximum text length (tlmax parameter) declared by the application program in its NETGET, 
NETGETF, NETGETL, or NETGTFL call and remains queued until: 

A NETGET, NETGETL, NETGETF, or NETGTFL call occurs for the connection and specifies 
an adequate text length (see section 51. 

A truncate-input asynchronous supervisory message (see section 3) is issued for the 
connection and a NETGET, NETGETL, NETGETF, or NETGTFL call occurs for the connection 
(see section 5). This action resolves the problem only for synchronous supervisory 
messages. 

A block header with an ibu value of 1 contains the actual length of the queued block in 
its tic field, given in character units specified by the act field. You can access 
this field with the reserved symbol ABHIBU (see section 4). 


Figure 2-8. Application Block Header Content for Upline Supervisory Nessages (Sheet 1 of 2) 
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tru Truncated data bit. When tru is 1, the synchronous supervisory message block associated 

with this block header has been truncated to fit into the text area used. Asynchronous 
supervisory messages are never truncated. This bit contains a meaningful value only after 
the application program has issued the data truncation control asynchronous supervisory 
message described in section T and only if that message affects transmissions on this 
connection. When truncation occurs, the block header for the truncated block contains the 
maximum number of complete transferred character bytes in its tic field. You can access 
this field with the reserved symbol ABHTRIJ Csee section Ai. 

res Reserved for CDC use. Reserved fields contain zero. 

tic Text length of the associated block, in character units specified by the act field, as 

follows: 

act='', tic is the number of central memory words occupied by the block. 

act=?, tic is the number of 8-bit bytes containing meaningful message fields. 

act=3, tic is the number of 12-bit bytes containing meaningful message fields. 

You can access this field with the reserved symbol ABHTLC <see section 41. 


Figure 2-8. Application Block Header Content for Upline Supervisory Messages (Sheet 2 of 2) 
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ha Symbolic header area address, specified as the application block header's location in a 

call to NETPUT or NETPUTF (see section 5). 

abt Application block type; abt is 3 for all supervisory messages. You can access this field 

with the reserved symbol ABHABT (see section 4). 

adr Application connection number of the logical connection to which the message block should 

be sent. This field can contain the values: 

=0, for asynchronous supervisory messages addressed to the host portion of the 

network software. 

=acn, for synchronous supervisory messages addressed to the Terminal Interface 
Program servicing the logical connection with the indicated nonzero 
application connection number. 

You can access this field with the reserved symbol ABHADR (see section 4). 

abn Application block number assigned to the message block being sent. This field is an 

18-bit integer that identifies a synchronous supervisory message block when the network 
software's processing of the block returns a block-delivered or block-not-delivered 
supervisory message. This field is generally ignored for asynchronous supervisory 
messages. If the message is a request for connection with another application program, 
that application program will receive this integer as part of the request; see the 
CON/ACRQ/R supervisory message description in section 3. You define the block number; it 
can be: 

A sequencing nunber 

The block's central memory address 

The block's mass storage address (physical record unit) 

An index value for a block control array or table 
An external label 

You can access this field with the reserved symbol ABHABN (see section 4). 

act Application character type used to encode the accompanying message block. The value 

declared for this field depends on the type of supervisory message involved; this field 
can have the values: 

=1, an asynchronous supervisory message packed in 60-bit transparent character 

bytes, one character per central memory word. 

=2, a synchronous supervisory message packed in 8-bit character bytes, 7.5 

bytes per central memory word; the recommended value. 

=3, a synchronous supervisory message packed in 8-bit characters within 12-bit 

bytes, 5 bytes per central memory word. 

You can access this field with the reserved symbol A8HACT (see section 4). 

tic Tgxt length of the accompanying block, in character units specified by the act field, as 

follows: 

act=1, tic is the number of central memory words occupied by the block. 

act=2, tic is the number of 8-bit bytes containing meaningful message fields. 

act=3, tic is the number of 12-bit bytes containing meaningful message fields. 

You can access this field with the reserved symbol ABHTLC (see section 4). 


Figure 2-9. Application Block Header Content for Downline Supervisory Messages 
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SUPERVISORY MESSAGES 


3 


This section describes all synchronous and asyn¬ 
chronous supervisory messages that are legal for 
application program communication with network 
software. These messages are described in the con¬ 
text of their use. 


MESSAGE MNEMONICS 

Figure 2-6 in section 2 shows the general format of 
a supervisory message. Note that this information 
is in the text area of the message and must be 
accompanied by an application block header as 
described in section 2. A supervisory message is 
Identified by the contents of Its primary function 
code field, error bit, response bit, and secondary 
function code field. This allows a supervisory 
message to be described by a mnemonic of the form 
shown in figure 3-1. Although many combinations of 
valid field values are possible, only certain com¬ 
binations are permitted. Table 3-1 lists these 
legal messages alphabetically by mnemonic. 

MESSAGE SEQUENCES 

Supervisory messages are always used in stereotyped 
sequences of one or more messages. Related messages 
(messages distinguished by the use of the error or 
response bits) are always part of multiple-message 
sequences. The messages described in the following 
subsections are discussed in the context of their 
normal sequences. Each sequence is illustrated with 
a figure that shows the sender and recipient of the 
messages in the sequence, and the direction of 
transmission of each message (arrows). 

Message sequences include the following: 

Managing logical connections 

Managing connection lists 

Controlling data flow 


pfc/sfc/sm 


pfc The reserved symbolic mnemonic for the 
contents of the primary function code 
field; this mnemonic can be any of those 
listed in figure 2-6 in section 2. 

sfc The reserved symbolic mnemonic of the 

contents of the secondary function code 
field; this mnemonic can be any of those 
listed in figure 2-6 in section 2, 
provided the secondary function code is 
legal for the primary function code used. 

sm A letter indicating the combined settings 
of the error and response bits; this 
letter can be: 

R Indicating an initial request 

supervisory message (bit setting 00) 

N Indicating a normal response 

supervisory message (bit setting 01) 

A Indicating an abnormal response 

supervisory message (bit setting 10) 


Figure 3-1. Supervisory Message 
Mnemonic Structure 


Converting blocks 

Truncating blocks 

Managing terminal characteristics 

Host operator communication 

Host shutdown 

Error reporting 


TABLE 3-1. LEGAL SUPERVISORY MESSAGES 


Message 

Mnemonic 

Message Meaning 

Type 

Block Header 
Fields 

Figure Number 
Defining 
Message 

BI/MARK/R 

Break-lndication-marker request 

Upline synchronous 

acn ^ 0 
act = 2,3 
tic = 2 

3-32 

CON/ACRQ/A 

Rejection of appllcation-to- 
application connection request 

Upline asynchronous 

acn = 0 

act = 1 
tic = 2 

3-13 

CON/ACRQ/R 

Applicatlon-to-applicatlon 
connection request 

Downline asynchronous 

acn = 0 
act = 1 
tic = 2 

3-12 
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TABLE 3-1. LEGAL SUPERVISORY MESSAGES (Contd) 


Message 

Mnemonic 

Message Meaning 

Type 

Block Header 
Fields 

Figure Number 
Defining 
Message 

CON/CB/R 

Connection broken 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-8 

CON/END/N 

All connection processing 
completed 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-10 

CON/END/R 

End all connection processing 

Downline asynchronous 

acn = 0 
act = 1 
tic > 2 

3-9 

CON/REQ/A 

Connection rejected 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-5 

CON/REQ/N 

Connection accepted 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-4 

CON/REQ/R 

Connection requested 

upline asynchronous 

acn = 0 
act = 1 
tic > 6 

3-3, 3-14 

CTRL/CCD/R 

CDCNET multiple device char¬ 
acteristics definitions 

Upline synchronous 

acn f 0 
act = 2, 3 
tic 2 ^ 

3-57.3 

CTRL/CHAR/A 

No CCP device characteristics 
changed 

Upline synchronous 

acn ^ 0 
act = 2, 3 
tic = 4 

3-50 

CTRL/CHAR/N 

Multiple CCP device character¬ 
istics defined 

Upline synchronous 

acn / 0 
act = 2, 3 
tic = 2 

3-51 

CTRL/CHAR/R 

Define multiple CCP device 
characteristics 

Downline synchronous 

acn f 0 
act = 2, 3 
tic > 2 

3-49 

CTRL/CTD/A 

No CDCNET device characteristics 
changed 

Upline synchronous 

acn = 0 
act = 2, 3 
tic = 5 

3-56 

CTRL/CTD/N 

CDCNET multiple device character¬ 
istics defined 

Upline synchronous 

acn = 0 
act = 2, 3 
tic = 2 

3-55 

CTRL/CTD/R 

Define CDCNET multiple device 
characteris tics 

Downline synchronous 

acn = 0 
act = 2, 3 
tic >_ 2 

3-57 

CTRL/DEF/R 

Redefine device characteristic 

Downline synchronous 

acn # 0 
act = 2, 3 

tic > 2 

3-48 

CTRL/RCC/A 

No CDCNET multiple device char¬ 
acteristics definitions returned 

Upline synchronous 

acn # 0 
act =2, 3 
tic > 2 

3-57.2 

CTRL/RCC/R 

Request CDCNET multiple device 
characteristics definitions 

Downline synchronous 

acn # 0 
act = 2, 3 
tic >_ 2 

3-57. 1 


3-2 
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TABLE 3-1. LEGAL SUPERVISORY MESSAGES (Contd) 


Message 

Mnemonic 

Message Meaning 

Type 

Block Header 
Fields 

Figure Number 
Defining 
Message 

CTRL/RTC/A 

Bad value In request device 
characteristics supervisory 
message 

Upline synchronous 

acn i' 0 
act =2,3 
tic = 4 

3-53 

CTRL/RTC/R 

Request current value of device 
characteristics 

Downline synchronous 

acn ^ 0 
act = 2, 3 
tic > 2 

3-52 

CTRL/TCD/R 

Device characteristics 
definitions 

Upline synchronous 

acn 4 0 
act = 2, 3 
tic >_ 2 

3-54 

DC/CICT/R 

Change application character type 
of connection input 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-43 

DC/STMR/R 

Set Inactivity timer 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-16.1 

DC/TRO/R 

Truncate upline block 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-45 

ERR/LGL/R 

Logical error 

Upline asynchronous 

acn = 0 
act = 1 
tic 3 

3-79 

FC/ACK/R 

Output block delivered 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-25 

FC/BRK/R 

Connection processing interrupted 
by break 

Upline asynchronous 

acn.= 0 
act = 1 
tic = 1 

3-28 

FC/INACT/R 

Connection Inactive 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-16 

FC/INIT/N 

Application ready for connection 
processing (connection initial¬ 
ized) 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-7 

FC/INIT/R 

NAM ready for connection process¬ 
ing (connection initialized) 

Upline asynchronous 

acn = 0 
act = 1- 
tic = 1 

3-6 

FC/NAK/R 

Output block not delivered 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-26 

FC/RST/R 

Reset connection 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-29 

HOP/ALT/R 

Operator alert 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-66 

HOP/BRK/R 

Operator break 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-67 


60499500 V 


3-3 









TABLE 3-1. LEGAL SUPERVISORY MESSAGES (Contd) 


Message 

Mnemonic 

Message Meaning 

Type 

Block Header 

Fields 

Figure Number 
Defining 
Message 

HOP/CMD/R 

Operator command 

Upline, asynchronous 

acn = 0 
act = 1 
tic = 2-6 

3-68 

HOP/DAY/R 

Dayfile command 

Downline asynchronous 

acn = 0 

act = 1 
tic = 1 

3-69 

HOP/DB/R 

Activate debug code 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-59 

HOP/DE/R 

Turn off debug code 

Upline asynchronous 

acn = 0 
act = 1 

tic = 1 

3-60 

HOP/DIS/R 

K-display data 

Downline asynchronous 

acn = 0 
act = 1 
tic = 2-210 

3-71 

HOP/DU/K 

Dump field length 

Upline asynchronous ; 

acn = 0 
act = 1 
tic = 1 

3-61 

HOP/END/R 

Operator and display 

Upline asynchronous 

acn = 0 
act = 1. 
tic = 1 

3-72 

HOP/IG/R 

Operator ignore 

Upline asynchronous 

acn = 0 
act = 1 

tic = 1 

3-73 

HOP/LG/R 

Network dayfile 

■ Downline asynchronous 

- acn = 0 
act = 1 
tic = 2-9 

3-70 

HOP/NOTR/R 

Turn off AIP tracing 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

, 3-63 

HOP/PAGE/R 

Operator page 

Upline asynchronous 

acn = 0 

act = 1 
tic = 1 

3-74 

HOP/REL/R 

Release debug log file 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-64 

HOP/RS/R 

Restart statistics gathering 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-65 

HOP/START/R 

Operator start 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-75 

HOP/TRACE/R 

Turn on AIP tracing 

Upline asynchronous 

acn = 0 
act = 1 

tic = 1 

3-62 

INTR/APP/R 

Application interrupt request 

Downline asynchronous 

acn = 0 

act = 1 
tic = 1 

3-35 


3 


60499500 V 









TABLE 3-1. LEGAL SUPERVISORY MESSAGES (Contd) 


Message 

Mnemonic 

Message Meaning 

Type 

Block Header 
Fields 

Figure Number 
Defining 
Message 

INTR/RSP/R 

Interrupt response 

Downline or upline 
asynchronous 

acn = 0 
act = 1 
tic = 1 

3-33, 3-36 

INTR/USR/R 

User Interrupt or user Interrupt 
re quest 

Upline asynchronous 

acn = 0 

act = 1 

tic = i 

3-31, 3-40 

LST/FDX/R 

Turn on full duplex operation for 
connections in list 

Downline asynchronous 

acn = 0 
act = L 
tic = 1 

3-24 

LST/HDX/R 

Turn on half duplex operation for 
connections in list 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-23 

LST/OFF/R 

Turn list processing for connec¬ 
tion off 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-20 

LST/OFF/R 

Turn list processing for 
connection off 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-20 

LST/ON/R 

Turn list processiag for 
connection on 

Downline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-21 

LST/SWH/R 

Switch application list number of 
connection 

Downline asynchronous 

acn = 0 
act = t 
tic = 1 

3-22 

RO/MARK/R 

Resume output marker 

Downline synchronous 

acn ^ 0 
act = 2,3 
tic = 2 

3-34 

SHUT/INSD/R 

Network shut-down in progress 

Upline asynchronous 

acn = 0 
act = 1 
tic = 1 

3-77 

- TCH/TCHAR/R 

Device characteristics rede¬ 
fined 

Upline asynchronous 

.acn = 0 
act = 1 
tic = 1 

3-47 

TO/MARK/R 

Terminate output marker 

Downline synchronous 

acn ^ 0 
act = 2, 3 
tic = 2 

3-37 


MANAGING LOGICAL 
CONNECTIONS 

Five messages are used in connection management. 
These are the CON/ACRQ, CON/REQ, CON/CB, CON/END, 
and FC/INIT. These messages as well as examples of 
how they are used in connecting devices to appli¬ 
cations, applications to applications, and later 
terminating these connections are discussed in this 
subsection. 


CONNECTING DEVICES TO APPLICATIONS 

After an application program has completed a NETON 
call, connection-request supervisory messages are 
sent to the application on behalf of each device 
seeking- connection. Request by-request, the appli¬ 
cation must decide whether to accept or reject the 
requested connection. Rejection might be neces¬ 
sary, for -example, when the application program 
receives a. connection request for a card reader and 
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it does not support batch devices. To respond to a 
connection-request-message, the application must 
return one of two similar messages, indicating that 
the application is either rejecting or accepting 
the connection request. Figure 3-2 shows the common 
message sequences in the connection establishment 
process. 

In this figure, arrows indicate the direction of 
transmission of each message. The general term 
Network Access Method (NAM) indicates the network 
host software sending or receiving the message, 
regardless of the software module actually involved. 

An application program cannot initiate a connection 
to a terminal. The connection-request supervisory 
message shown in figure 3-3 can only be an Incoming 
asynchronous message. The application program's 
first action in processing a device-to-appllcation 
connection sequence is to issue the asynchronous 
connection-accepted supervisory message shown in 
figure 3-4, or the connection-rejected message shown 
in figure 3-5. 

The CONNET flag is defined in the CON/REQ/R super¬ 
visory message and indicates whether the terminal- 


to-appllcation connection is through CCP or 
CDCNET. This flag is set by NAM when NAM creates 
and returns the connection-request supervisory 
message to the application program requesting the 
connection to the device. 


If the application program accepts the connection 
(assuming that no change has occurred in the status 
of the requesting terminal), the network software 
informs the application program that the connection 
is ready for data transmission. This is done by 
sending the asynchronous Initialized-connection 
message shown in figure 3-6 upline to the applica¬ 
tion program. If conditions have not changed and 
the application program can still service the con¬ 
nection, it responds by Issuing the connection- 
initialized message shown in figure 3-7. Data 
transmission on the logical connection can then 
begin. After the network software receives the 
connection-initialized message, the application 
program can send output to console devices or wait 
for input from them. An application program cannot 
send or receive any supervisory messages or data 
blocks on a connection until connection initial¬ 
ization processing has been completed. 


Application NAM 


Message 


■< 






CON/REQ/R 

CON/REQ/N 

FC/INIT/R 

FC/INIT/N 


The application program can now send and receive messages over the logical connection. 


Application NAM 

- 


Message 

CON/REQ/R 

CON/REQ/A 


The application program has rejected the logical connection. 


Application 


NAM 


*- 


Message 

CON/REQ/R 

CON/REQ/N 


-► 


CON/CB/R 

CON/END/R 


-<- CON/END/N 

Although the application program was willing to accept it, the logical connection 
could not be completed. 


Figure 3-2. Oevice-to-Application Connection Supervisory Message Sequences 


3-6 


6049y500 V 




5958 54 5251 49 47 45 45 41 59 55 51 29 25 25 2120 1716 12 


con 0 0 req res 



log fain 


logname 


a a a 
h I h I h r 

d e ahtl ahsl ahem ahec ahlp ahep 
b s 



ahdt I ahdf ahcc ahms 


See NOS Administration Handbook 


a a a a 

t I t I t t 

p attt t atis 
c 



Symbolic address of the application program's text area receiving this asynchronous super 
visory message. 

Primary function code 631^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of reserved symbol CON. 

<• 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in. section 4. Its value is defined as the value of the reserved symbol REQ. 

Reserved by CDC. 
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acn 


Application connection number assigned to this Logical connection, if the connection is estab¬ 
lished; 1 < minacn < acn £ maxacn < 4095, where minacn and maxacn are minimum and maximum 
\/aLues established by the application program in its NETON call. (See section 5.i You can 
access this field with the reserved symbol CONACN, as described in section 4. 

abl Application block limit, specifying the maximum number of data or synchronous supervisory 

message blocks the program can have outstanding (unacknowledged as delivered by the network 
software) on this connection at any time. This value is established for the device involved 
in the logical connection when the device is described in the network configuration file. 

This field has the range 1 £ abl £7. You can access this field with the reserved symbol 
C0NA3L, as described in section 4. 

sdt Subdevice type. 

If dt=1 or 12 through 15 (card reader or a site-defined device), this field can have the 
values: 

0 029 punch patterns are the default for each job deck 

1 026 punch patterns are the default for each job deck 

2 Reserved for CDC use 

thru 

11 

12 Reserved for installation use 

thru 

15 

If dt=2 or 12 through 15 (line printer or a site-defined device), this field can have the 
values: 

0 64-character ASCII print train 

1 64-character BCD (CDC scientific) print train 

2 95-character ASCII print train 

3 Reserved for CDC use 

thru 

11 

12 Reserved for installation use 

thru 

15 

If dt=4 or 12 through 15 (plotter or a site-defined device), this field can have the values: 

0 Instructions must be packed in 6-bit bytes 

1 Instructions must be packed in 3-bit bytes 

2 Reserved for CDC use 

thru 

11 

12 Reserved for installation use 

thru 

15 


Figure 3-3. Connection-Request (CON/REQ/R) Supervisory Message Format, 
Device-to-AppLi cation Connections (Sheet 2 of 7) 
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dt Device type of the terminal device. This field can have the values: 

0 Console (interactive terminal) 

1 Card reader; your program should reject connections with this device type 

2 Line printer; your program should reject connections with this device type 

3 Card punch; your program should reject connections with this device type 

4 Plotter; your program should reject connections with this device type 

5 Reserved for COC use 
thru 

11 

12 Reserved for installation use 

thru 

15 

Devices with a device type of zero can be serviced as interactive virtual terminals. Devices 
with device types of 1 through 4 must be serviced as batch devices. You can access this 
field with the reserved symbol CONDT, as described in section 4. Applications other than RBF 
are only allowed to do input/output on batch devices if the devices are of types 0 or 12 
through 15. 

tc Terminal class assigned to the terminal either in the network configuration file or by the 

terminal operator. The terminal class determines the parameters and ranges valid for redefi¬ 
nition of the device. The device is serviced by the TIP according to the attributes asso¬ 
ciated with the terminal class. These attributes are discussed in the Terminal Interfaces 
reference manual. The terminal class field can have the values: 

0 Reserved for CDC use. 

1 Archetype terminal for the class is a Teletype Corporation Model 30 Series. 

2 Archetype terminal for the class is a CDC 713-10, 722-10, 751-1, 752, or 756. 

3 Archetype terminal for the class is a CDC 721. 

4 Archetype terminal for the class is an IBM 2741. 

5 Archetype terminal for the class is a Teletype Corporation Model 40-2. 

6 Archetype terminal for the class is a Hazeltine 2000, operating as a tele¬ 

typewriter. 

7 Archetype terminal for the class is a DEC VT100 (ANSI X3.64 standard). 

8 Archetype terminal for the class is a Tektronix 4000 Series, operating as a tele- 

typewriter. 

9 Archetype terminal for the class is a HASP (post-print) protocol multileaving 
workstation. 

10 Archetype terminal for the class is a CDC 200 User Terminal. 

11 Archetype terminal for the class is a CDC 714-30. 

12 Archetype terminal for the class is a CDC 711-10. 

13 Archetype terminal for the class is a CDC 714-10/20. 

14 Archetype terminal for the class is a HASP (pre-print) protocol multileaving work¬ 
station. 

15 Archetype terminal for the class is a CDC 734. 

16 Archetype terminal for the class is an IBM 2780. 


Figure 3-3. Connection-Request (COM/REO/R) Supervisory Message Format, 
Device-to-Application Connections (Sheet 3 of 7) 
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17 

Archetype 

terminal 

for 

the 

class 

is an IBM 

3780. 

18 

Archetype 

terminal 

for 

the 

class 

is an IBM 

3270. 

19 

Reserved 

for CDC use. 






thru 

27 

28 Reserved for installation use. 

thru 

31 

You can access this field with the reserved symbol CONT, as described in section 4. 

ric Restricted interactive capability (for consoles only). This field can have the values: 

0 Terminal has unrestricted interactive capability. 

1 Terminal has restricted interactive capability. 

Applications should limit the amount of interactive dialog with a terminal that has 
restricted interactive capability. Such terminals (for example a 2780 or 3780) in which the 
console is emulated by a card reader and line printer are not truly interactive. You can 
access this field with the reserved symbol CONR, as described in section 4. 

ord Device ordinal, indicating a unique device when more than one device with the same device 

type is part of the same terminal. This field can have the value: 

0 All interactive consoles 

1 Batch devices 

thru 

7 

The device ordinal is assigned to the device when the device is defined in the network con¬ 
figuration file. You can access this field with the reserved symbol COMORO, as described in 
section 4. 

tname Terminal device name, assigned to the device in the network configuration file. This name is 

one to seven 6-bit display code letters and digits, left-justified with blank fill; the first 
character is always alphabetic. The terminal device name is the element name used by the net¬ 
work operator to identify the device. You can access this field with the reserved symbol 
CONTNM, as described in section 4. 

pw If the device is a console, this field specifies the maximum number of characters in a 

physical line of input or output, 0 or 20 ^ pw ^ 255. If the device is a batch card reader 
or card punch, this field specifies the maximum number of characters in an input or output 
record. If the device is a batch line printer, this field specifies the maximum number of 
characters in a line of output, 50 < pw £ 255. If the device is a plotter, this field 
specifies the maximum number of character bytes of plotter information in a record of 
output. Page width of consoles is discussed in the Terminal Interfaces reference manual. 

You can access this field with the reserved symbol CONPW, as described in section 4. The pw 
value can be assigned in the network configuration file or the user can set console pw from 
the terminal. Default value depends on terminal class. 

pi Page length of a device, specifying the number of physical lines that constitute a page. The 

page length is assigned to the terminal either in the network configuration file or by the 
terminal operator; page length is one of the attributes associated with the terminal class by 
the TIP, and is discussed in the Terminal Interfaces reference manual. This field can have 
the values 0 or 8 £ pi £ 255 for interactive consoles, but is always 60 for batch devices. 

You can access this field with the reserved symbol CONPL, as described in section 4. 

ownert Terminal device name of the owning console (for batch devices only). For batch devices, this 

field contains one to seven 6-bit display code characters, left-justified with blank fill; 
for console devices, this field is zero. You can access this field with the reserved symbol 
CONOWNR, as described in section 4. 


Figure 3-3. Connection-Request (CON/REQ/R) Supervisory Message Format, 
Device-to-Application Connections (Sheet 4 of 7) 
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connet 


Network type flag indicating the type of network for the connection. This field can have the 
values: 


0 The device is connected to CCP. 

1 The device is connected to COCNET. 

You can access this field with the reserved symbol CONNET, as described in section 4. 

si Access level of the communications line in use. Access to information or resources requiring 

a security level higher than this value should be prohibited. This value is the AL parameter 
from the NDL statement defining the communication line used by the terminal. This field can 
have the values 0 £ si < 7. You can access this field with the reserved symbol CONSL, as 
described in section 4. 

dbz Block size in characters for any downline block from the application to NAM. The downline 

block size is assigned to the device in the network configuration file and is a function of 
line speed, device type, and terminal class as described in the Network Definition language 
reference manual. This field can have the values 1 < dbz < 2043. The values are advisory 
only. You can access this field with the reserved symbol CONDBZ, as described in section 4. 

bw The hardwired line indicator. A 0 (zero) indicates that the device is not hardwired; a 1 

indicates that the device is hardwired. 

Istat Loaned connection status. This is a reason code which is set as the result of a terminal 

connection being loaned to a secondary application. This field can have the values: 

0 Normal connection request. 

8 Loan request from primary to secondary application. 

9 Reserved for CDC use. 

thru 

15 

16 User is not validated for secondary application. 

17 Secondary application issued NETOFF with the loan connection outstanding. 

18 Secondary application failed. 

19 Reserved for CDC use. 

20 Secondary application terminated the connection. 

21 Secondary application refused the connection. 

22 Secondary application not available. 

23 Secondary application connection limit reached. 

You can access this field with the reserved symbol CONLOAN, as described in section 4. 

ubz Upline block size (in multiples of 100 characters) for a console device. Upline block size 

(in PRUs) of a batch device. Console connections with an upline block size of 0 send blocks 
of 100 characters or blocks created when a linefeed is entered from the console. You can 
access this field with the reserved symbol CONUBZ, as described in section 4. 

xbz Transmission block size (in characters) of the device. This is the number of characters in 

an output transmission block that CCP sends to the terminal. You can access this field with 
the reserved symbol CONXBZ, as described in section 4. 

logfara The NOS family name supplied by the terminal operator during login or by the local configu¬ 

ration file as an automatic login parameter. This family name is one to seven 6-bit display 
code letters and digits, left-justified with blank fill. You can access this field with the 
reserved symbol CONFAH, as described in section 4. 

famord The NOS family ordinal corresponding to the logfam field contents. You can access this field 

with the reserved symbol CONFO, as described in section 4. 


Figure 3-3. Connection-Request (CON/REQ/R) Supervisory Message Format, 
Device-to-AppIication Connections (Sheet 5 of 7) 
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Logname The NOS user name supplied by the terminal operator during login. This user name is one to 

seven 6-bit display code letters, digits, or asterisks, left-justified with blank fill. You 
can access this field with the reserved symbol CONUSE, as described in section 4. 

usrind The NOS user index corresponding to the logname field contents. You can access this field 

with the reserved symbol CONUI, as described in section 4. 

ahmt User validation control word defined in the NOS validation file. You can access this word 

with the reserved symbol CONAtflIT, as described in section 4. The NOS Administration Handbook 
section on the HODVAL command explains the use of the fields in this word. 

ahpt Index value of allowed units plotted per file for the connection's user name. See NOS HODVAL 

PT parameter. 

ahmti Index value of allowed magnetic tapes for the connection's user name. See NOS MODVAL HT 

parameter. 

ahrp Index value of allowed removable packs for the connection's user name. See NOS MODVAL RP 

parameter. 

ahdb Index value of allowed deferred batch jobs for the connection's user name. See NOS HODVAL DB 

parameter. 

ahtl Index value of central processor time limit per job step for the connection's user name. See 

NOS HODVAL TL parameter. 

ahsl Index value of system resource unit limit for the connection's user name. See NOS HODVAL JL 

parameter. 

ahem Index value of allowed central memory field length for the connection's user name. See NOS 

MODVAL CM parameter. 

ahec Index value of allowed extended central storage field length for the connection's user name. 

See NOS MODVAL EC parameter. 

ahlp Index value of allowed lines printed per file for the connection's user name. See NOS HODVAL 

LP parameter. 

ahep Index value of allowed cards punched per file for the connection's user name. See NOS MODVAL 

CP parameter. 

ahds User validation control word defined in the NOS validation file. You can access this word 

with the reserved symbol CONAHDS, as described in section 4. The NOS Administration Handbook 
section on the HODVAL command explains the use of the fields in. this word. 

ahdsi Index value of allowed direct access file size for the connection's user name. See NOS 

MODVAL DS parameter. 

ahfc Index value of allowed maximum number of permanent files in catalog for the connection's user 

name. See NOS MODVAL FC parameter. 

ahes Index value of allowed maximum total indirect access file storage space for the connection's 

user name. See NOS MODVAL CS parameter. 

ahis Index value of allowed indirect access file size for the connection's user name. See NOS 

MODVAL IS parameter. 

ahsc Allowed security count for the connection's user name. See NOS MODVAL SC parameter, 

ahdt Allowed number of detached jobs for the connection's user name. See NOS HODVAL DT parameter. 

ahdf Allowed number of calls per job to the COMPASS MSG macro for dayfile entries under the 

connection's user name. See NOS HODVAL DF parameter. 

ahcc Allowed number of NOS commands per job for the connection's user name. See NOS MODVAL CC 

parameter. 

ahms Allowed number of mass storage physical record units per job for the connection's user name. 

See NOS HODVAL MS parameter. 


Figure 3-3. Connection-Request CCON/REQ/R) Supervisory Message Format, 
Device-to-Application Connections (Sheet 6 of V) 
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User validation control word defined in the NOS validation file. You can access this field 
with the reserved symbol CONAAWC as described in section 4. The NOS Administration Handbook 
section on the HODVAL command (AW parameter) explains the use of the fields in this word. 

This word contains permission bits for the connection's user name. A set bit indicates that 
the user name is allowed that permission. 

atwdCatpa) User validation control word defined in the NOS validation file. You can access this word 

with the reserved symbol CONATWD, as described in section 4. The NOS Administration Handbook 
section on the HODVAL command explains the use of the fields in this word. 

Terminal parity associated with the connection's user name (0 means that PA command is 
assumed to require value of E; 1 means that PA command is assumed to require value of 0). 

See NOS HODVAL PA parameter. 

atro Number of idle characters associated with the connection's user name. See NOS HODVAL RO 

parameter. 

atpx Transmission mode (0 means that EP command is assumed to require value of N; 1 means that EP 

command is assumed to require value of Y). See NOS HODVAL PX parameter. 

attt Terminal type associated with the connection's user name. See NOS HODVAL TT parameter. One 

of the following: 


Teletypewriter compatible terminal, using ASCII codes 
Block mode terminal, using ASCII codes 
C0C-713-compatible terminal 


49 and 48 Reserved for CDC use 


Character set associated with the connection's user name (0 means the NOS NORHAL mode 6-bit 
display code, set is assumed to be used in permanent files accessed through the Interactive 
Facility; 1 means the NOS ASCII mode 6/12-bit display code set is assumed to be used in 
permanent files accessed through the Interactive Facility). See NOS HODVAL TC parameter. 

Initial Interactive Facility subsystem associated with the connection's user name. See NOS 
HODVAL IS parameter. One of the following: 

Bit Subsystem 

46 BASIC 

45 BATCH 

44 EXECUTE 

43 FORTRAN 

42 FTNTS 

If no bit is set, the NULL subsystem is used; if all bits are set, the ACCESS subsystem is 
used. 

Date user name was created, in the format yymmdd. 

Date user name permissions were last changed, in the format yymmdd. 

The user validation control word. It is defined in the NOS validation file. 


Figure 3-3. Connection-Request (CON/REQ/R)'Supervisory Hessage Format, 
Device-to-Application Connections (Sheet 7 of 7) 
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ta 

con 

req 

res 

acn 

nxp 


set 


59 51 49 43 35 23 11 9 5 0 



Symbolic address of the application program's text area from which this asynchronous super- 
supervisory message is sent. 

Primary function code 63^^_ access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CON. 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol REQ. 

Reserved by COC. Reserved fields contain zero. 

Application connection number assigned by the network software to this end of the logical con¬ 
nection being established. The value placed in this field must be the value used in the 
CON/REQ/R message to which this message is a response. You can access this field with the 
reserved symbol CONACN, as described in section 4. 

No transparent input allowed flag. This field can have the values: 

0 Deliver network data blocks when the xpt field in the accompanying block header 
word is 1 

1 Discard network data blocks when the xpt field in the accompanying block header 

word is 1 

The change-input-character-type supervisory message, described later in this section, permits 
an application to change to or from allowing transparent mode terminal device input. If 
transparent input is not-allowed any transparent input from a terminal device destined for 
the application will be discarded. You can access this field with the reserved symbol DCNXP, 
as described in section 4. 

Synchronous supervisory message input character type. This field can have the values: 

0 Application character type 2 should be used 

1 Application character type 3 should be used 

Indicates the input character type required by the application program for synchronous super¬ 
visory messages. The change-input-character-type supervisory message, described later in 
this section, allows an application to change the input character type of synchronous super¬ 
visory messages. You can access this field with the reserved symbol DCSCT, as described in 
section 4. 


Figure 3-4. Connection-Accepted (CON/REQ/N) Supervisory Message Format, 
All Connection Types (Sheet 1 of 2) 
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act 

Application input character type, specifying the form of character byte packing that the 
application program requires for input data blocks from the logical connection. This field 
can have the values: 


0 

Reserved for CDC use. 


1 

60-bit words. Can be used for appLication-to-application connections within a 
host. Cannot be used for terminal-to-application connections. 


2 

8-bit characters in 8-bit bytes, packed 7.5 bytes per central memory word; if the 
input is not transparent mode, the ASCII character set described in table A-2 is 
used. 


3 

8-bit characters in 12-bit bytes, packed 5 bytes per central memory word, right- 
justified with zero fill within each byte; if the input is not transparent mode, 
the ASCII character set described in table A-2 is used. 


4 

6-bit display coded characters in 6-bit bytes, packed 10 characters per central 
memory word; the characters used are the ASCII set of CDC characters described in 
table A-1. Cannot be used for appLication-to-appLication connections or connec¬ 
tions with batch devices. 


5 

thru 

11 

Reserved for CDC use. 


12 

thru 

255 

Reserved for site-defined use. 


The act value declared applies only to input on the connection and can be changed by a 

DC/CICT/R supervisory message at any time during the existence of this Logical connection. 

You can access this field with the reserved symbol CONACT, as described in section 4. 

aLn 

Application List number assigned by the application program to this logical connection; 

0 £ aln < 63. You can access this field with the reserved symbol CONALN, as described in 
section %. 


Figure 3-4. Connection-Accepted (CON/REQ/N) Supervisory Message Format, 
AIL Connection Types (Sheet 2 of 2) 
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ta 


req 


ta 


59 


51 49 


43 


35 


23 


req 


Symbolic address of the application program's text area from which this asynchronous super* 
tfisory message Is sent. 

Primary function code 63i^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CON. 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol REQ. 

Reason code, specifying the reason the application program is refusing to complete the connec¬ 
tion. This field is ignored. You can access this field with the reserved symbol RC, as 
described in section 4. 

Application connection number assigned by the network software to this end of the logical con¬ 
nection being rejected. The value placed in this field must be the value used in the 
CON/REQ/R message to which this message is a response. Upon receipt of this message, the net¬ 
work software can reuse this application connection number for a different logical connection 
with the same program. You can access this field with the reserved symbol CONACN, as 
described in section 4. 

Reserved by COC. Reserved fields contain zero. 


Figure 3-5. Connection-Rejected (CON/REQ/A) Supervisory Message Format, All Connection Types 
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ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

■fc Primary function code 83.]^_ You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol FC. 

init Secondary function code 7. You can access this field with the reserved symbol SFC, as 

defined in section 4. Its value is defined as the value of the reserved symbol INIT. 

res Reserved by COC. 

acn Application connection number assigned by the network- software to the program end of the logi¬ 

cal connection that has been initialized. This value is the same as that used in previous 
CON/REQ/R and CON/REQ/N messages. You can access this field with the reserved symbol FCACN, 
as described in section 4. 


Figure 3r6. Initialized-Connection CFC/INIT/R) Supervisory Message Format 
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59 


51 49 


43 


35 


23 


ta 


fc 


imt 


ta 


f c 


init 


res 

acn 


Symbolic address of the application program's text area from which this asynchronous super¬ 
visory message is sent. 

Primary function code 83i^, You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol FC. 

Secondary function code 7. You can access this field with the reserved symbol SFC, as 
defined in section 4. Its value is defined as the value of the reserved symbol INIT. 

Reserved by CDC. Reserved fields contain zero. 

Application connection number assigned by the network software to the program end of the logi 
cal connection that has been initialized. This value placed in this field must be the value 
used in the FC/INIT/R message to which this message is a response. You can access this field 
with the reserved symbol FCACN, as described in section 4. 


Figure 3-7. Connection-Initialized (FC/INIT/N) Supervisory Message Format 


If the application program rejects the connection, 
no further action by the program or the network 
software occurs. If the application program accepts 
the connection but the network software cannot Ini¬ 
tialize the connection, the asynchronous connection- 
broken supervisory message shown in figure 3-8 is 
sent to the application program. This connection- 
broken message requires the application program to 
respond by issuing an end-connection asynchronous 
message, as shown in figure 3-9. The network soft¬ 
ware finishes this sequence by responding with the 
connection-ended asynchronous supervisory message 
shown in figure 3-10. 


If the application program does not follow these 
message sequences, a logical-error asynchronous 
supervisory message is issued to the program. This 
message is discussed at the end of this section. 


CONNECTING APPLICATIONS TO 
APPLICATIONS 

When one application program needs to be connected 
to another, the first application program sends a 
supervisory message request to the network software, 
asking for establishment of a logical connection. 
Unlike device-to-application connections, the net¬ 
work software permits more than one logical connec¬ 
tion to exist between two application programs. 

The only requirements for such connections are that 


both programs be running, have completed NETON calls 
(as described in section 5), and are not already 
connected to the maximum number of application pro¬ 
grams permitted. 

Figure 3-11 shows the most common message sequences 
in the process of establishing a connection between 
two applications. 

In this figure, arrows indicate the direction of 
transmission of each message. The general term 
Network Access Method (NAM) indicates the network 
host software sending or receiving the message, 
regardless of the software module actually involved. 

All three sequences begin when the first application 
program issues the asynchronous supervisory message 
shown in figure 3-12. This request-application- 
connection message causes the network software 
either to issue the asynchronous application- 
connection-reject message shown in figure 3-13, or 
to use a message sequence similar to that used for 
device-to-appllcation connections. If the latter 
occurs, both application programs receive the form 
of the asynchronous connection-request supervisory 
message with the form shown in figure 3-14. Both 
programs may accept the connection by issuing the 
connection-accepted asynchronous supervisory 
message shown in figure 3-4. If so, then both must 
exchange the initiallzed-connectlon and connection- 
initialized messages of figures 3-6 and 3-7 with the 
network software before any data can be transmitted 
on the logical connection. 
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ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

con Primary function code 63^^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CON. 

cb Secondary function code 5. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CB. 

cc Reason code, specifying the cause of the broken connection. This field can have the values: 

0 Reserved for CDC use. 

1 Communication has been lost with the element at the other end of the logical 
connection. If the element is an application program, it failed, was shutdown, or 
ended the connection. If the element is a device, the line disconnected or the 
device failed. Also, the NOP could have disabled the communication line, logical 
link, trunk, or terminal device associated with the connection. 

2 The network software could not complete establishment of the connection because 
the CON/REQ/N supervisory message contains an invalid parameter. 

3 The secondary application aborted the loaned connection by specifying ABORT as the 
next application. 

4 Reserved for CDC use. 
thru 

8 

9 User requested the connection be broken (consoles only). 

10 Passive device followed the owning consoles 

11 Operator disabled the element. 

12 Hardware failure. 

13 PSN issued a clear or a restart on the logical channel. 

14 Batch application-to-application data discarded. 

15 Reserved for CDC use. 
thru 


You can access this field with the reserved symbol RC, as described in section 4. 

acn Application connection number assigned by the network software to the program end of the 

logical connection being broken. This number is always one for which the application program 
has previously received a CON/REQ/R message. You can access this field with the reserved 
symbol CONACN, as described in section 4. 

res Reserved by CDC. 

I Loan indicator, indicating this was a loaned connection. 

You can access this field with the reserved symbol CONLOAN, as described in section 4. 


Figure 3-8. Connection-Broken (CON/CB/R) Supervisory Message Format 
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51 49 


aname 


res 

Optional (data for secondary application or next 
(0-52 central memory words) 

application)' 


Symbolic address of the application program's text area from which this asynchronous super¬ 
visory message is sent. 

Primary function code 63i^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CON. 

Secondary function code 6. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol ENDD. 

Application connection number assigned by the network software to this end of the logical con¬ 
nection being terminated. The value placed in this field must be the value used in the 
CON/REQ/R message beginning this message sequence. Upon receipt of this message, the network 
software issues a response message and can reuse this application connection number for a 
different logical connection with the same program. You can access this field with the 
reserved symbol CONACN, as described in section 4. 

Reserved by CDC. Reserved fields contain zero. 

Loan indicator. This flag is set when the application program requests that the connection 
be loaned to a secondary application. In this case, aname specifies the name of the 
secondary application. Also, the loaning application can append up to 52 central memory 
words of data which will be passed to the secondary application. You can access this field 
with the reserved symbol CONLOAN, as described in section 4. 

Name of next application, one to seven 6-bit display coded characters consisting of Letters 
or digits only with a Leading alphabetic character, left-justified and blank filled within 
the field. This field is 0 for appLication-to-appLication connections. For device-to- 
appLication connections, this field can contain the following: 

0 The network software alone determines the next application program that the 

device is connected to, or disconnects the device if that is an appropriate 
action. For a secondary application, the connection will be returned to the 
primary application. 

NVF NVF reinitiates the Login sequence appropriate for the device or disconnects 

command the device from the host. The following commands are valid: 


BYE or 
LOGOUT 


Causes the device to be disconnected from the host. 


HELLO Reinitiates Login for the device. If dialog is possible and 
or required, the Login prompting sequence begins. 

LOGIN 

Valid The device at the other end of the logical connection is switched (without NVF 

appLi- prompting dialog) to connection with the indicated application, if possible, 

cation The name placed in the field must be the element name used to define the 

name referenced application program in the validation file (VALIDUs). For the 

secondary application, this connection will be automatically returned to the 
primary application. 

For the secondary application, the Loaned connection will be terminated and will not be 
returned to the primary application. The user will be prompted for another application 
name. This parameter is ignored for the primary application. 
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ta 

con 

end 

rc 


acn 


res 

L 
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Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code 63ig. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CON. 

Secondary function code 6. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol ENDD. 

Lending return code. This field can have the values: 

0 Normal lending confirmation. 

1 No loan occurred. This value occurs when a secondary application tried to loan a 
loaned connection. 

2 The application program tried to loan an application-to-application connection. The 
connection will be terminated normally. 

You can access this field with the reserved symbol CONLOAN, as described in section 4. 

Application connection number assigned by the network software to the program end of the logi¬ 
cal connection that has been terminated by the CON/END/R message to which this message is a 
response. After issuing this message, the network software can reassign this application con¬ 
nection number to another logical connection with the same program. You can access this 
field with the reserved symbol CONACN, as described in section 4. 

Reserved by CDC. 

If 1, this CON/ENO/N supervisory message is for a loaned connection. You can access this 
field with the reserved symbol CONLOAN, as described in section 4. 


Figure 3-10. Connection-Ended CCON/END/N) Supervisory Message Format 
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Application 1 NAM 

Application 2 

Message 

- ► 


CON/ACRQ/R 


- ► 

CON/REQ/R 

^ - 


CON/REQ/R 



CON/REQ/N 

- ^ 


CON/REQ/N 

— 

- ► 

FC/INIT/R 

- 


FC/INIT/R 



FC/INIT/N 

- ► 


FC/INIT/N 


The requested logical connection is established and enabled for input and output. 

Application 1 NAH Application 2 Message 

-► CON/ACRQ/R 

- CON/ACRO/A 

Application program 2 is not available. The logical connection is not established. 


Application 1 

NAM 

Application 2 Message 

CON/ACRQ/R 





^ CON/REQ/R 

CON/REQ/R 





CUN/KcQ/A 

CON/REQ/N 

CON/CB/R 

- 




-► 

CON/END/R 

- 


CON/END/N 


Application program 2 rejects the logical connection. 


Figure 3-11. Application-to-Application Connection Supervisory Message Sequences 
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ta Symbolic address of the application program's text area from which this asynchronous super¬ 

visory message is sent. 

con Primary function code You ^gn access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of reserved symbol CON. 

acrq Secondary function code 2. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol ACRQ. 

lid Logical Identifier. It is optional but at least one of the parameters LID or NAnE2 must be 

specified for interhost connections. 

If a logical identifier is specified, then that LID should have been previously specified in 
the LIDCHid file. .(See NOS Installation Handbook.) If a LID is specified and NAHE2 is not 
specified, then a physical identifier (PID) that is linked to NAM at the time of issuing the 
CON/ACRQ message is used as NAME2 in the OUTCALL search. 

If both LID and a NAHE2 parameters are specified, then NAHE2 is assumed to be a PID, and must 
have been previously specified as a legal PID for the LID in the LIDCMid file, and the PID 
must be linked to NAM at the time of issuing a CON/ACRQ message. 

Note: For NAM to be able to detect that a PID is linked to NAM, the PID must have been 
previously used as a PID=xxx parameter in an OUTCALL statement in the LCF previously created 
by NDLP. 

You can access this field with the reserved symbol CONALID, as described in section 4. 

namel Outcall Identifier, 1 to 7 6-bit display code letters or digits (the first must be a letter), 

left-justified and blank-filled. This parameter is used to uniquely identify the appropriate 
OUTCALL definition that establishes a connection to another application. 

You can access this field with the reserved symbol CONANM, as described in section 4. 


Figure 3-12. Request-Application-Connection (CON/ACRQ/R) Supervisory Message Format (Sheet 1 of 3) 
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names Outcall identifier. This parameter is optional (see LID parameter) and must be 1 to 3 

display code letters or digits, left-justified and blank-filled. When this parameter is 
explicitly specified in the CON/ACRQ message, or implied by the by the LID; together with 
NAHE1, it is used to select the appropriate outcall definition from the collection of OUTCALL 
definitions previously specified by the Network Definition Language OUTCALL statement during 
the creation of the local configuration file CLCF). The combination of NAME1 and NAMES 
(implicit or explicit) must appear as NAHE1 and NAMES or PID on an OUTCALL statement. For 
intra-host connections, both the LID and the PID can be zero. If the application supplies 
its own outcall block, the explicit or implicit PID must have appeared on a PID parameter in 
the OUTCALL statement of a previously created LCF. You can access this field with the 
reserved symbol CONANMS, as described in section 4. 

a1 Priority flag. When a1 = 0, this indicates that priority is not set. When a1 = 1, this 

indicates that priority is set. The a1 parameter is an application supplied OUTCALL 
parameter. An application can supply its own OUTCALL parameters if it is a privileged 
application (SSJ= entry point, or a non-zero SSID). This parameter does not need to appear 
in the OUTCALL statement in the LCF. You can access this field with the reserved symbol 
CONAPRI, as described in section 4. 

dbl Downline block limit, specifying the number of downline blocks that can be outstanding 

between the host computer (NAM) and the other end of this logical connection. The value 
chosen determines how many blocks of data the NPU queues from the total number of outstanding 
blocks (ABL parameter value) of the size specified by the dbz. This parameter is optional 
and has a range of 1 £ dbl < 7). The dbl parameter is an application supplied OUTCALL 
parameter. An application can supply its own OUTCALL parameters if it is a privileged 
application (SSJ= entry point, or a non-zero SSID). This parameter does not need to appear 
in the OUTCALL statement in the LCF. You can access this field with the reserved symbol 
CONAOBL, as described in section 4. 

dbz , Downline block size, specifying the recommended maximum number of 8-bit character bytes in 

any network data block sent on the connection. This field can have values 0 £ dbz £ 20, 
where 0 and 1 both indicate 100-byte blocks. The dbz parameter is an application supplied 
OUTCALL parameter. An application can supply its own OUTCALL parameters if it is a 
privileged application (SSJ= entry point, or a non-zero SSID). This parameter does not need 
to appear in the OUTCALL statement in the LCF. You can access this field with the reserved 
symbol CONADBZ, as described in section 4. 

abl Application block limit, specifying the maximum number of data or synchronous supervisory 

message blocks the program can have outstanding (unacknowledged as delivered by the network 
software) on this connection at any one time. This field has the range 1 < abl < 7. The abl 
parameter is an application supplied OUTCALL parameter. An application can supply its own 
OUTCALL parameters if it is a privileged application (SSJ= entry point, or a non-zero SSID). 
This parameter does not need to appear in the OUTCALL statement in the LCF. You can access 
this field with the reserved symbol CONAABL, as described in section 4. 

ubl Upline block limit, specifing the maximum number (1 £ ubl £31) of blocks that the NPU can 

have outstanding (unacknowledged) to the calling host. This parameter applies only to X.25 
connections. The ubl parameter is an application supplied OUTCALL parameter. An application 
can supply its own OUTCALL parameters if it is a privileged application (SSJ= entry point, or 
a non-zero SSID). This parameter does not need to appear in the OUTCALL statement in the 
LCF. You can access-this field with'the reserved symbol CONAUBL, as described in section 4. 

ubz Upline block size, specifying the maximum number (1 £ upz £ 2000) of bytes that the NPU can 

send to the calling host in a block. This parameter applies only to X.25 connections. The 
ubz parameter is an application supplied OUTCALL parameter. An application can supply its 
own OUTCALL parameters if it is a privileged application (SSJ= entry point, or a non-zero 
SSID). This parameter does not need to appear in the OUTCALL statement in the LCF. You can 
access this field with the reserved symbol CONAUBZ, as described in section 4. 

ws Send window size used by CCP for this connection. This parameter specifies the decimal 

number (1 £ ws £ 7) of outstanding packets allowed for the X.25 connection. This parameter 
applies only to X.25 network application-to-application connections and is ignored on other 
appLication-to-application connections. The us parameter is an application supplied OUTCALL 
parameter. An application can supply its own OUTCALL parameters if it is a privileged 
application (SSJ= entry point, or a non-zero SSID). This parameter does not need to appear 
in the OUTCALL statement in the LCF. You can access this field with the reserved symbol 
CONAWS, as described in section 4. 


Figure 3-12. Request-Application-Connection (CON/ACRQ/R) Supervisory Message Format (Sheet 2 of 3) 


3-22 


60499500 V 




dpi-s Send data packet Length, specifying the maximum number of data octets (8-bit bytes) an X.25 

packet can contain. This parameter applies only to X,25 network appLication-to-appLication 
connections and is ignored on other appLication-to-application connections. The dpLs 
parameter is an application supplied OUTCALL parameter. An application can supply its own 
OUTCALL parameters if it is a privileged application (SSJ= entry point, or a non-zero SSID). 
This parameter does not need to appear in the OUTCALL statement in the LCF. You can access 
this field with the reserved symbol CONDPLS, as described in section A. 

facn Number of facility groups. This parameter applies only to X.25 network 

appLication-to-appLication connections. The facn parameter is an application supplied 
OUTCALL parameter. An application can supply its own OUTCALL parameters if it is a 
privileged application (SSJ= entry point, or a non-zero SSID). In this case, the facn 
parameter does not need to appear in the OUTCALL statement in the LCF. You can access this 
field with the reserved symbol CONFACN, as described in section 4. 

cudl Length of user data (in octets). The cudl parameter is an application supplied OUTCALL 

parameter. An application can supply its own OUTCALL parameters if it is a privileged 
application (SSJ= entry point, or a non-zero SSID). This parameter does not need to appear 
in the OUTCALL statement in the LCF. You can access this field with the reserved symbol 
CONAUDL, as described in section 4. 

■fad Facility code length, specifying the Length of a facility field within the central memory 

word. This parameter applies only to X.25 network application-to-application connections. 

The fad parameter is an application supplied OUTCALL parameter. An application can supply 
its own OUTCALL parameters if it is a privileged application (SSJ= entry point, or a non-zero 
SSID). This parameter does not need to appear in the OUTCALL statement in the LCF. 

fac Facility code, specifying the facility code for a facility field. This parameter applies 

only to X.25 network appLication-to-application connections. The fac parameter is an 
application supplied OUTCALL parameter. An application can supply its own OUTCALL parameters 

if it is a privileged application (SSJ= entry point, or a non-zero SSID). This parameter 

does not need to appear in the OUTCALL statement in the LCF. 

prid The protocol identification. This parameter tells the PSN or remote node of a direct X.25 

link how call user data is to be used. This parameter applies only to X.25 network 
application-to-appLication connections and must be 1 to 8 hexadecimal digits. Left-justified, 
and zero-filled. If CUDL ^ 0, only the first 6 hexadecimal digits are passed to the X.25 
network, and the Last two hexadecimal digits are zeroed. The prid parameter is an 
application supplied OUTCALL parameter. An application can supply its own OUTCALL parameters 

if it is a privileged application (SSJ= entry point, or a non-zero SSID). This parameter 

does not need to appear in the OUTCALL statement in the LCF. 

udata Call user data. If the destination host is a NOS system running network products, the first 

12t octets must be of the form sss dd aaaaaaa, where: 

sss is the 3 character ASCII equivalent of the SNODE (sendng node number) value, 

right-justified, zero filled. 

dd is the 2 character ASCII equivalent of the DHOST (destination host number) 

value, right-justified, zero filled. 

aaaaaaa is the 7 character ASCII equivalent of the called application's application 
name. Left-justified, blank filled. 

The remainder of the udata field (0-112 octets) is passed to the called application as user 
data. 

The called host/application (if accessed through an X.25 network) must be able to support the 
Fast Select Facility, if more than 12 octets of information are specified. 

Note: For applications accessing foreign hosts through an X.25 network, the 4 octets of the 
PRID field and the (up to) 124 octets of the UDATA field are combined into the (up to) 128 
octets of used data as defined by the CCITT recommendation for X.25 networks. 

You cannot access this field with NFETCH. 


tAn octet is 8 bits of information. 


Figure 3-12. Request-Application-Connection (CON/ACRQ/R) Supervisory Message Format (Sheet 3 of 3) 
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ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

con Primary function code 63-|g. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of reserved symbol CON. 

acrq Secondary function code 2. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol ACRO. 

rc Reason code, specifying the cause for rejecting the connection request. The field is 

actually made up of two 4 bit subfields, rcl and rc2. The rcl field comprises bits 40 
through 43 and the rc2 field comprises bits 36 through 39. 

The rc2 field is used so that the application can determine what action to take when it 

receives a CON/ACRQ/A message and it provides some general information about the source of 

the trouble. This field can have the following values: 

1 = Critical error in call request detected by source host (only LIO/PID/NDL 

configuration changes or application code changes can solve the problem). 

2 = Critical error in call request detected by destination host. 

3 = Source host temporarily cannot make the connection (resources are currently not 

available, but they might become available without operator intervention). 

4 = Destination host temporarily cannot make the connection. 

5 = Source host cannot make the connection for an indefinite period of time (resources 

can be made available by operator intervention such as enabling a LID/PID, network 
element, or bringing up a system or subsystem). 

6 = Destination host cannot make the connection for an indefinite period of time. 

Thus if rc2 = 1 or 2, the application should not try establishing the connection again; it 
should notify the user and/or host operator that the connection is not possible. 

If rc2 = 3 or 4, then the application can retry the CON/ACRQ message after a short time, and 

if rc2 = 5 or 6, then it can retry the CON/ACRQ after a longer time. 

The rcl field is used in combination with the rc2 field to uniquely identify the exact source 

of the trouble, so that the user/operator can take the appropriate action to fix the 

problem. The full 8-bit reason code field can therefore have the following values: 

2 = Network error detected by destination host. Contact system analyst at destination 
host. 

4 = Connection number conflict between source and destination host. Retry connection 
request. 

17 = Invalid LID/PID combination was specified. Correct LID/PID in OUTCALL block. 

18 = Called application is not defined in system record (CONTNAP) at destination host. 

Contact system analyst. 

19 = Network Validation Facility (NVF) temporarily cannot process connection request. 

Retry later. 

20 = Called application cannot accept any more connections and another copy of the 

application cannot be started up. Retry later. 

Figure 3-13. Application-Connection-Reject (CON/ACRQ/A) Supervisory Message Format (Sheet 1 of 4) 
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22 - Called application is not running and cannot be started automatically. Request 
that host operator start up called application. 

33 = Calling application is not privileged (it is not allowed to issue OUTCALL). 

Contact network administrator to make the application a privileged application in 
the LCF. 

34 = OUTCALL block has facility parameters more than 4 octets long. Correct the OUTCALL 

block. 

35 = NAH temporarily cannot complete the connection request because the link to the 

destination host is not available. Retry later. 

37 = Specified PID is valid but is currently not available. Retry later. 

38 = Called application is disabled. Request that host operator enable the application. 

49 = Application specified its own OUTCALL parameters but there was no corresponding 

OUTCALL entry in the LCF for the same PID. Correct the OUTCALL parameters in the 
CON/ACRO/A. 

50 = OUTCALL block had user parameters more than 124 octets long. Correct the OUTCALL 

block. 

53 = Source host is not allowing any new connections because it is in idle or disabled 

state. Retry later. 

54 = Destination host is not allowing any new connections because it is in idle or 

disabled state. Retry later. 

65 = Application specified its own OUTCALL parameters but there was no matching OUTCALL 

entry in the LCF. Correct the OUTCALL parameters in the CON/ACRQ/R. 

66 = Destination host could not find a matching INCALL block in its LCF. Correct the 

OUTCALL parameters in the CON/ACRQ/R. 

81 = Calling application has already reached its maximum number of allowed connections. 

Retry after at least one connection ends. 

82 = Name of application specified in CON/ACRQ/R is invalid. Correct the name. 

97 = Retry limit has been reached for calling application. No more application-to- 

application connection requests (CON/ACRQ/R) should be issued. The reason codes 
for the previous CON/ACRQ/A should be analyzed. 

98 = Destination host could not find a matching INCALL block in the LCF with a matching 

facility code. Correct the facility code in the OUTCALL block of the CON/ACRQ/R. 

100 = Network Validation Facility (NVF) in the destination host is not available. Retry 
later. 

114 = Application requested Fast select but matching INCALL block in LCF at the 

destination host does not have Fast select specified. Correct the OUTCALL block of 
the CON/ACRQ/R to not select Fast select. 

129 = No X25 TIP in NPU at source host. Contact system analyst to rebuild CCP with X25 

TIP. 

130 = Error in incoming call packet header. Contact system analyst about possible PSN 

problem. 

132 = Unknown packet from remote; the packet received is not a call accepted or call 

connected. This is assumed to be caused by a call collision. Retry later. 

133 = No available logical channel at source host; active number of SVCs are greater than 

enabled SVCs. Contact the network administrator about enabling additional SVCs. 
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134 = No available logical channel at destination host; active number of SVCs are greater 
than enabled SVCs. Contact the network administrator at the destination host to 
enable some more SVCs. 

145 = X25 subTIP not available in NPlI at source host and/or no application-to-application 

virtual circuits defined. Contact network administrator for rebuilding CCP, and/or 
modifying the NCF. 

146 = X25 subTIP not available in NPU at destination host and/or no application-to- 

application virtual circuits defined. Contact network administrator at destination 
site for rebuilding CCP, and/or modifying the NCF. 

147 = NPU at source host temporarily has no buffer space to support the connection. 

Retry later. 

148 = NPU at destination host temporarily has no buffer space to support the connection. 

Retry later. 

149 = X. 25 packet level unable to locate title for port number 0 in the Network Products 

Gateway, or for a non-zero port number in the X. 25 Gateway. 

161 = Problem detected by X.25 network at local host. X.25 network CCC=13. Local 

procedure error. Clear problem with X.25 network administration. 

162 = Remote host not known. Correct DD field in UDATA in OUTCALL entry in the LCF or in 

the CON/ACRQ/R message. 

163 = No connection available; all SVCs (outside lines) have been used. Retry later. 

164 = Problem detected by X.25, network at destination host. X.25 network CCC=1. Number 

at destination host is busy. Retry later. 

165 = X.25 line is down at source host. Retry later. 

166 = X.25 line is down at destination host. Retry later. 

178 = Unknown subTIP connection; the PRID field is not CO (PAD) or Cl (A-A). Fix the 
PRID field in the OUTCALL entry in the LCF or in the CON/ACRQ/R message. 

180 = Problem detected by X.25 network. X.25 network CCC=5. X.25 network congestion. 
Retry later. 

182 = CCP cannot complete the connection because the link at the destination host is not 
enabled. The network administrator should be contacted to enable the logical link. 

194 = Problem detected by X.25 network. X.25 network CCC=3. Invalid facility request. 

Change the facility specification in the OUTCALL of CON/ACRQ/R. 

195 = Connection number conflict between source host and source NPU. Retry later. 

196 = No connection number available in NPU at destination host. Retry later. 

198 = Problem detected by X.25 network. X.25 network CCC=15. PPOA out of order. Retry 
later. ■ 

210 = Problem detected by X.25 network. X.25 network CCC=21. Incompatible destination. 
Clear the problem with the X.25 network administration. 

213 = CCP cannot complete the connection because the link at the source host is not 

enabled. The network operator should be contacted to enable the logical link. 

214 = Remote host hot available. Retry later. 

225 = Invalid port number in OUTCALL block. Correct port number in OUTCALL block of 

CON/ACRQ/R. 

226 = Problem detected by X.25 network. X.25 network CCC=19. Reverse charging not 

subscribed to. Change OUTCALL portion of CON/ACRQ/R to not request reverse 
charging. 
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230 = Problem detected by X.25 network. X.25 network CCC=9. Destination host out of 
order. Wait until destination comes back up; then retry. 

242 = Problem detected by X.25 network. X.25 network CCC=29. Fast select not subscribed 
to. Change OUTCALL portion of CON/ACRQ/R to not use fast select. 

You can access this field with the reserved symbol RC, as described in section 4. 

abn Application block number. This field contains the abn of the previous CON/ACRQ/R message if 

there was one; otherwise, this field contains a zero. You can access this field with the 
reserved symbol CONAABN, as described in section 4. 

reserved Reserved by CDC. 

namel Outcall identifier, 1 to 7 6-bit display code letters or digits (the first must be a letter), 

left-justified and blank-filled. This parameter is used to uniquely identify the appropriate 
OUTCALL definition that establishes a connection to another application. You can access this 
field with the reserved symbol CONANH, as described in section 4. 

name2 Outcall identifier, 1 to 3 display code letters or digits, left-justified and blank-filled. 

This parameter is optional (see the LID parameter). When explicitly specified in the 
CON/ACRQ message, or when implied by the LID together with NAMEl; it is used to select the 
appropriate OUTCALL definition from the collection of outcall definitions previously 
specified by the Network Definition Language OUTCALL statement during the creation of the 
local configuration file (LCF). The combination of NAME1 and NAME2 (implicit or explicit) 
must appear as NAMEI and NAHE2 or PID on an OUTCALL statement. For intra-host connections, 
both the LID and the PID can be zero. 

If the application supplies its own outcall block, then the explicit or implicit PID must 
have appeared on a PID parameter in the OUTCALL statement of a previously created LCF. 

You can access this field with the reserved symbol C0NANM2, as described in section 4. 


Figure 3-13. Application-Connection-Reject (CON/ACRQ/A) Supervisory Message Format (Sheet 4 of 4) 



ta Symbolic address of the application program’s text area receiving this asynchronous super¬ 

visory message. 

con Primary function code 63-]^. You can access this field with-the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of reserved symbol CON. 

req Secondary function code 0. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol REQ. 

res . Reserved by CDC. Reserved fields contain zero. 

Figure 3-14. Connection-Request (CON/REQ/R) Supervisory Message Format, 
Application-to-Application Connections (Sheet 1 of 2) 


60499500 W 


3-27 















acn Application connection number assigned to this logical connection; 1 £ minacn < acn < maxacn 

< 4095, where minacn and maxacn are minimum and maximum values establTshed.by The application 
program in its NETON call. (See section 5.) You can access this field with the reserved 
symbol CONACN, as described in section 4. 

abl Application block limit, specifying the maximum number of data or synchronous supervisory 

message blocks the program can have outstanding (unacknowledged as delivered bythe network 
software) on this connection at any time. This value is established when the connection is 
described in the local configuration file. If your application program initiated the 
connection request, this value comes from the ABL parameter of the NDL OUTCALL statement used 
by your program; if another application program initiated the connection request, the initial 
value comes from the ABL parameter of the NDL INCALL statement used by that program. This 
value is also supplied from the abl in the C0N/ACR9 if the application supplies its own 
OUTCALL parameters. This field has the range 1 ^ abl £7. You can access this field with 
the reserved symbol CONABL, as described in section 4. 

dt Device type of the connection. This field can have the values: 

5 Application-to-applicat ion connection within the same host 

6 Application-to-application connection between two hosts 

You can access this field with the reserved symbol CONDT, as described in section 4. 

app Application name. This field contains the application name of the other application program 

for intrahost application-to-application connections; otherwise, this field contains zero. 

shost Source host identifier. This field contains the node number of the host in which the other 

application program runs if this CON/REQ/R is received by the called application. The value 
is in 6“bit display code characters, left-justified with blank fill. The calling application 
receives a C0N/RE9/R with the nameZ field of the previous C0N/ACR9/R message or the nameZ 
value of the corresponding OUTCALL parameter block. 

abn Application block number. This field contains the abn value assigned by your application 

program to the CON/ACRQ/R supervisory message if your program initiated the connection 
request; otherwise, this field contains a zero. You can access this field with the reserved 
symbol CONABN, as described in section 4. 

dbz Downline block size. The recommended maximum number of 8-bit character bytes in any network 

data block sent on the connection. If your application program initiated the connection 
request, this value comes from the DBZ parameter of the NDL OUTCALL statement used by your 
program; if another application program initiated the connection request, the initial value 
comes from the DBZ parameter of the NDL INCALL statement used by that program. This field 
can have the values 1 £ dbz £ Z043. You can access this field with the reserved symbol 
CONDBZ, as described in section 4. 

ubz Upline block size. The number of 8-bit bytes (in multiples of 100) the network will deliver 

in each upline network data block on the connection. If your application program initiated 
the connection request, this value comes from the UBZ parameter of the NDL OUTCALL statement 
used by your program. If another application program initiated the connection request, the 
initial value comes from the UBZ parameter of the NDL INCALL statement used by that program. 
This field can have the values 0 £ ubz £ ZO, where 0 and 1 both indicate 100-byte blocks. If 
ubl is not specified, the default value of Z is used. You can access this field with the 
reserved symbol CONUBZ, as described in section 4. 

cudl The call for the user's data length expressed in the number of octets. This field is set to 

zero if there is no call user data. 

You can access this field with the reserved symbol CONUOL, as described in section 4. 

udata Optional call user data. This is the call user data specified by the calling application in 

the CON/ACRQ/R supervisory message from a NOS host; or, it is the 13tn through 128th octets 
of call user data an X.Z5 network. Allows applications to send a small amount of data to 
each other without actually establishing a connection via the fast select facility on an X.25 
network. 

You cannot access this field with NFETCH. 


Figure 3-14. Connection-Request (CON/REQ/R) Supervisory Message Format, 
Application-to-Application Connections (Sheet 2 of 2) 
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Neither application program can send or receive any 
supervisory messages or data blocks on a connection 
until connection initialization processing has been 
completed. 

If either program cannot complete or service the 
logical connection, it can reject the connection 

request by Issuing the asynchronous connection- 
rejected message described in figure 3-5. When 

this occurs, the other application program must 
exchange the connection-broken, end-connection, and 
connection-ended asynchronous supervisory messages 
with the network software. No further action is 

required by the rejecting application program. 

If either application program does not follow the 
message sequences shown in figure 3-15, a logical- 
error asynchronous supervisory message is issued. 
This message is discussed at the end of this 

section. 

A logical connection established between two appli¬ 
cation programs does not necessarily have the same 
application connection number for both applications. 
The network software assigns the application con¬ 
nection number to each end of the logical connection 
Independently. The application connection number 
is unique within all connections of each application 
program; for example, the same logical connection 
can have an acn parameter of 2 for ■ application 
program A (which accepted one previous connection) 
but an acn parameter of 4 for application program B 
(which accepted three previous connections). 

Privileged applications can specify OUTCALL param¬ 
eters in optional words 2-10 of the CON/ACRQ/R 
sequence. This allows the applications to have 


more control over an outgoing call request. The 
application specifies a complete OUTCALL block 
except for the NDL-supplied SNODE, DNODE, PORT, and 
DTE address parameters. NAM obtains these param¬ 
eter values from the first OUTCALL statement defined 
in the LCF that has a matching NAME2 (PID). 


MONITORING CONNECTIONS 

As soon as a logical connection is completely 
initialized by the network software and an appli¬ 
cation program, Che network software starts an 
inactivity timer. If no data traffic occurs on the 
connection within the inactivity time interval, the 
network software informs the application program of 
the condition by sending it an inactive-connection 
(FC/INACT/R) supervisory message (shown in figure 
3-15). The inactivity timer is then restarted. 

Each time a network data block or a synchronous 
supervisory message is transmitted on the logical 
connection, the inactivity timer is restarted. 
Each time the inactivity timer expires, the network 
software sends another inactive-connection super¬ 
visory message to the application program. 

The inactivity time interval can be specified by 
the application program or can default to the value 
specified by the INACT parameter in the NIP control 
statement. If the INACT parameter was not speci¬ 
fied in the NIP control statement, the network 
software uses a default inactivity time interval of 
10 minutes. The application program specifies the 
inactivity time Interval by sending NAM the set- 
timer supervisory message (also shown in figure 
3-15). 


Application NAM Message 

- FC/INACT/R 

No activity has occurred on the connection for the time interval specified by the INACT 
parameter from the NIP .control statement, for 10 minutes (if the the INACT parameter was 
not specified on the NIP control statement), or for the time interval specified by the 
application program in a set-timer (DC/STMR/R) supervisory message sent to NAM by the 
application program. 

---► DC/STMR/R 

The network software resets the inactivity timer to send an inactive-connection 
(FC/INACT/R) supervisory message-to the application program when the time interval 
specified in the set-timer (DC/STHR/R) supervisory message elapses and no activity has 
occurred on the connection. If the time interval specified in the set-timer supervisory 
message is zero, the inactivity timer is deactivated and the network software stops 
sending inactive-connection supervisory messages to the application program. 


Figure 3-15. Connection Monitoring Message Sequences- 
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The connection monitoring sequence consists of the 
asynchronous inactive-connection (FC/INACT/R) 
supervisory message shown in figure 3-16 and the 
asynchronous set-timer (DC/STMR/R) supervisory 
message shown in figure 3-16. 1. The inactive- 
connection supervisory message is only advisory. 
No response is required from the application pro¬ 
gram. The network software restarts the inactivity 
timer as soon as the inactive-connection super¬ 
visory message is Issued. The application- 
sped fied-tlme-lnterval flag in the inactive- 
connection supervisory message indicates whether 
the supervisory message was triggered by a normal 
network inactivity timeout or by an application- 
program-specified timeout. 

The set-timer supervisory message can be issued by 
the application program as often as necessary. 
Each time the network software receives the super¬ 
visory message, it restarts the inactivity-timer to 
expire at the end of the specified time period. 

The application program can designate whether the 
specified inactivity time interval is a one-time 
change or a permanent change to the Inactivity 
timeout period. This is done by setting the 


permanent-timer flag in the supervisory message to 
the appropriate value. If the inactivity time 
interval change is a one-time change, the inactivity 
timer is reset to the normal network timeout- 
interval when the timer is restarted due to either 
the timer expiring or data traffic occurring on the 
connection. If the inactivity time interval change 
is a permanent change, all future inactivity- 
timeouts are based on this applicatlon-program- 
specified-time-interval. 


The application program can also use the set-timer 
supervisory message to direct the network software 
to stop reporting an inactive connection. This is 
done by specifying a time interval of zero seconds 
and setting the permanent-timer flag to one. The 
network software stops sending inactive-connection 
supervisory messages for the connection specified 
in the set—timer supervisory message. There is no 
response to the set-timer supervisory message 
unless the connection number is Invalid. In this 
case, a logical-error (ERR/LGL/R) supervisory 
message is returned. If the specified time 
Interval is 0 and the permanent-time-interval flag 
is not set, the supervisory message is ignored. 


59 51 49 43 35 23 0 


fc 

0 

0 

inact 

res 

acn 

res 

a 

t 








f 


ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

fc Primary function code 831^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol FC. 

inact Secondary function code 4. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol INACT. 

res Reserved by CDC. 

acn Application connection number assigned by the network software to the program end of the 

logical connection reported as inactive. The value in this field is always nonzero and is 
the value used in a CON/REQ/R supervisory message processed by the application program. You 
can access this field with the reserved symbol FCACN, as described in section 4. 

atf Application-specified-time-interval flag. This field can have the values: 

0 Supervisory message triggered by the expiration of a network software time interval. 

1 Supervisory message triggered by expiration of an application-specified-time-interval 

(from a DC/STMR/R supervisory message). 

You can access this field with the reserved symbol FCATF, as described in section 4. 


Figure 3-16. 


Inactive-Connection (FC/INACT/R) Supervisory Message Format 
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P 


time 


Symbolic address of the application program's text area receiving this asynchronous 
supervisory message. 

Primary function code C2^g. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol DC. 

Secondary function code 02. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol STMR. 

Reserved by CDC. Reserved fields should contain zero. 

Application connection number. This is assigned by the network software to the program end 
of the logical connection for which the application wants the inactivity timer set. The 
value used in this field can be either zero or the value used in a CON/REQ/R message 
processed by the application program. This field can have the following values: 

=0 The inactivity timer is reset to the specified value for all connections. 

^0 The specified connection has its inactivity timer reset. 

You can access this field with the reserved symbol DCACN, as described in section 4. 

Permanent-time-interval flag. This field can have the values: 

0 The inactivity timer is reset to the application-specified value for this one-time 
only. 

1 The inactivity timer is permanently changed to the application-specified value. 

You can access this field with the reserved symbol DCPERHT, as described in section 4. 

Inactivity-tirae-interval, in seconds, for triggering the FC/INACT/R supervisory message. 

You can access this field with the reserved symbol DCTIME, as described in section 4. 


Figure 3-16.1 Set-Timer (DC/STMR/R) Supervisory Message Format 


TERMINATING CONNECTIONS 

A logical connection can be terminated any time 
after establishment of it begins. This disconnec¬ 
tion can be initiated by an application program or 
by the network software. These two possibilities 
have separate corresponding supervisory message 
sequences, as shown in figure 3-17. 

Logical connection termination is Initiated by the 
network whenever such conditions as hardware fail¬ 
ure, a dialup line being disconnected without a 
formal logout by a terminal operator, and failure 
of another (connected) application program occur. 
The general case of this is shown by the second 
message sequence in the figure, a sequence already 
encountered as part of the connection establishment 
sequences discussed earlier in this section. 

The sequence begins when the network software sends 
the connection-broken message of figure 3-8 to the 
application program. The network software discards 
any network data blocks or synchronous supervisory 
messages sent by the application program on the 


connection between the time this asynchronous 
supervisory message is queued and the time it is 
processed by the application program. When the 
application program receives this message, it can 
still fetch any upline blocks queued on the logical 
connection. As soon as it has fetched all out¬ 
standing blocks, the application program must issue 
an end-connection message of the form shown in 
figure 3-9. The network software responds with the 
asynchronous connection-ended message described in 
figure 3-10. The application connection number of 
the terminated logical connection then becomes 
available for use with another logical connection. 


Application-initiated termination of a logical con¬ 
nection occurs whenever the application program 
processes a terminal operator's request to end con¬ 
nection, or in any other situation where the appli¬ 
cation program has finished exchanging blocks over 
the logical connection. The message sequence is the 
first one shown in figure 3-17. This sequence 
begins when the application program issues an asyn¬ 
chronous end-connection supervisory message.' 
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Application 

NAM 

Message 



CON/END/R 



CON/END/N 



The Logical 
application 
number can 
nection by 

connection is terminated by the 
program. The application connection 
be reassigned to another logical con- 
the network software. 

Application 

NAM 

Message 

- 


CON/CB/R 


The Logical connection is terminated by the net¬ 
work. The application program can salvage data 
in transit by fetching any blocks queued. 

-► CON/END/R 

- CON/END/N 

The application connection number can be 
reassigned to another Logical connection by the 
network software. 


Figure 3-17. Connection Termination 
Message Sequences 


The format of the end-connection message is 
described in figure 3-9. This message permits the 
application program to influence connection switch¬ 
ing or disconnection processing performed for the 
device after it is disconnected from the applica¬ 
tion program. The effects of this end-connection 
message vary according to the aname field contents 
and whether the device is a batch or interactive 
console device. 

When a' zero aname parameter is used, a console 
device is prompted for the name of the next program 
the device should be connected to, unless the user 
is allowed access only to the disconnected applica¬ 
tion program. In this instance, the device's log¬ 
ical connection is processed by NVF as if an aname 
value of BYE or LOGOUT was specified. 


When a valid application name is used in the aname 
field, a console connection is disposed of in one 
of three ways.' If the specified application 
program is available and the login user name of the 
console is allowed access to it, the console 
connection is switched directly to the new appli¬ 
cation program. This switch is performed ■ without 
dialog between NVF and a console operator. The 
network software performs the switch by sending a 
connection-request supervisory message for the 
console to the specified application program. 

If the specified application program is not avail¬ 
able or the login user name does not permit the 
terminal to access that program, Che console con¬ 
nection is not switched. In this case, a console 
is informed of the condition with the message 
APPLICATION NOT PRESENT or USER ACCESS NOT POSSIBLE 
- CONTACT NETWORK ADMIN. The terminal operator is 
then prompted for another application program name, 
unless the console was configured for a full auto¬ 
matic login procedure and the user name in that 
procedure validates for access only to the discon¬ 
nected application program. In this instance, all 
of the terminal's ended logical connections are 
processed by NVF, as if an aname value of BYE or 
LOGOUT was specified. 

The connection is loaned to the specified appli¬ 
cation program if: ' 

the specified application program is available, 

the login user name has permission to access 

i t, and 

the loan bit in the CON/END/R supervisory 

message is set. 

The application connection number (ACN) of this 
loaned connection is reserved. The lending connec¬ 
tion application program is the primary application 
and the receiving connection application is the 
secondary application. The loaned connection is 
returned to the primary application when the 
secondary application returns it, fails, or tries 
to loan a loaned connection. Upon returning the 
connection, the reserved connection number in the 
primary application will be reused and, if the 
primary application is not available, the connec¬ 
tion is automatically switched to NVF for the next 
application prompt. 
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When an NVF command is used in the aname field, 
disconnection processing depends on the command 
used and whether the device is a batch or inter¬ 
active one. The HELLO or LOGIN command causes NVF 
to initiate a manual login dialog with an inter¬ 
active device. The BYE or LOGOUT command causes 
NVF to disconnect a console device from the host. 


When your program ends a connection with a passive 
device (a batch device of device types 1 through 
4), any aname value you supply is ignored. NVF 
disposes of the passive device connection in the 
same manner as it does the device's owning console 
connection. That is: 


If your program already disconnected the owning 
console for the device, NVF attempts to connect 
the device to the same program as the owning 
console; if the owning console is disconnected 
from the host, NVF disconnects the passive 
device as well. 


If your program has not already disconnected 
the owning console for the device, NVF attempts 
to reconnect the device to your program. If 
your program rejects the reconnection, NVF 
keeps the device connected to itself until your 
program disconnects the owning console for the 
device. 


On dialup lines, consoles without connections to 
hosts are asslgEied to a disconnection queue. When 
all consoles on the dialup line are assigned to the 
disconnection queue, a timer for the line is 
started. When the timer for the line expires, the 
dialup line is physically disconnected. This dis¬ 
connection causes physical disconnection of all 
devices on the line, including any passive devices 
still connected to an application program (the 
connection is broken from the application pro¬ 
gram's viewpoint). The network software effectively 
hangs up the telephone, but the devices can be 
reconnected after a new dlal-ln procedure. 

On hardwired lines, no disconnection occurs when 
ail interactive devices on the line are timed out. 
Because the line is not disconnected in this 
instance, passive devices still connected to appli¬ 
cation programs remain connected to those programs. 

While a' console is queued for disconnection, any 
terminal operator keyboard entry removes all the 
devices of that terminal from the disconnection 
queue and reconnects them to NVF for a new manual 
login procedure. The data entered is discarded by 
the network software and therefore can be anything 
the operator wishes. 


MANAGING CONNECTION LISTS 

There are five asynchronous supervisory message 
sequences used for connection list management. Each 
sequence consists of one message. Issued by the 
application program. 


Three of these sequences, as shown in figure 3-18, 
control list polling and list assignment. Ihe 
other sequences, shown in figure 3-19, control the 
duplexing mode used during list processing. 


CONTROLLING LIST POLLING 

Connection list polling control consists of enabling 
or disabling the fetching of input blocks from a 
single logical connection when the list that the 
connection is assigned to is polled. All connec¬ 
tions are initially enabled for list processing 
without application program action. Each time the 
application program polls the list number that it 
has associated with a specific connection, blocks 
queued from that connection can be returned to the 
program. 


If the program requires the list to be polled 
without returning any blocks queued from the 
connection, the asynchronous supervisory message 
shown in figure 3-20 causes the next poll of the 
list to exclude the connection. This turn-list¬ 
processing-off message effectively disables list 
processing for the connection. This message is not 
acknowledged by the network software and remains in 
effect until canceled by the asynchronous turn-list- 
processing-on message shown in figure 3-21. 

The turn-list-processing-on message is Issued by 
the application program to enable list processing 
and input for a specific connection. This message 
causes the next poll of the list number associated 
with the indicated connection to Include the con¬ 
nection's data block queue. The network software 
does not acknowledge this message. If the message 
is issued when list processing already has been 
enabled for the connection, no error occurs. The 
message remains in effect until canceled by a turn- 
llst-processing-off supervisory message. 

Enabling list processing for a logical connection 
does not cause a- queued block to be returned from 
that connection the next.time the connection's list 
is polled. Connections on a list are searched in a 
loop starting with, the connection following the 
connection from which data was last obtained. 
Disabled connections are skipped during the polling 
process; enabled connections and connections in 
half-duplex mode for which no output has been sent 
are included in the polling process. 

The list number associated with a specific connec¬ 
tion is determined by the application program when 
it accepts the logical connection. This list num¬ 
ber can be changed while the connection exists by 
issuing the change-connection-list supervisory mes¬ 
sage shown in figure 3-22. The network software 
does not acknowledge this asynchronous message, but 
the change is effective at the time of the next 
poll of the new list number. After the change- 
connection-list message is issued by the application 
program, polls of the old list number cannot return 
blocks queued from the affected connection. 
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Application 


NAM 


Message 

LST/OFF/R 


When the List number associated with the affect¬ 
ed Logical connection is next polled by the 
application program, no blocks will be returned 
from the connection. 


Application 


NAM 

—► 


Message 

LST/ON/R 


When the List number associated with the affect¬ 
ed logical connection is next polled by the 
application program, blocks might be returned 
from the connection. 


Application 


NAM 


Message 

LST/SWH/R 


When the new List number associated with the 
affected logical connection is next polled by 
the application program, blocks might be 
returned from the connection. 


Figure 3-18. Connection List Polling Control 
Message Sequences 


Application 

NAM 

Message 


-► 

LST/FDX/R 


When the List number associated with the 
affected logical connection is next polled by 
the application program, blocks can be returned 
from the affected Logical connection regardless 
of the previous types of blocks output on the 
connection. 


Application 

NAM 

Message 


-► . 

LST/HDX/R 


When the list number associated with the 
affected logical connection is next polled by 
the application program, blocks of application 
block type 1 or a single block of block type 2 
are returned from the affected connection only 
if a block of block type 2 or a LST/ON/R 
message has been sent downline on the 
connection since the Last upline block of block 
type 2 was delivered to the program. In 
effect, message input to the program is 
disabled until message output is complete. 


Figure 3-19. Connection List Duplexing 
Message Sequences 


Polling of connection lists Is performed through 
application calls to the AlP routines NETGETL and 
NETGTFL, These.routines are described In section 5. 


CONTROLLING LIST DUPLEXING 

Upline and downline transmissions on logical con¬ 
nections usually occur in a full-duplex mode. In 
full duplex mode, the number and occurrence of com¬ 
plete upline message blocks is not related In any 
way to the number or occurrence of downline message 
blocks. Message Input and output Is logically 
Independent and can become unsynchronized. 

The list processing feature of NAM can be used In 
conjunction with a set of asynchronovis supervisory 
messages to avoid loss of Input and output synchro¬ 
nization on a logical connection. These messages 
can be used to switch the connection to and from a 
half duplex mode of Input and output. 

In half duplex mode, delivery of an upline block of 
block type 2 or 7 turns off additional list proc¬ 
essing for the connection until a downline block of 
block type 2 or 7 or a LST/ON/R message is sent on 
the same connection. In effect, application program 
Input obtained through NETGETL or NETGTFL calls must 
alternate with output for the connection, because 
no other sequence of input and output is possible 
using those calls. 

An application program begins network access with 
its AIP list processing code automatically enabled 
for full-duplex operation of all logical connec¬ 
tions. The program can change a single connection 
to half-duplex operation at any time during network 
access by issuing the asynchronous supervisory mes¬ 
sage shown in figure 3-23, with the appropriate 
application connection number included in the acn 
field. Alternatively, the program can change all 
existing and any future connections by issuing the 
same supervisory message with an acn field value of 
zero. There is no response to either form of this 
message. 

When half-duplex operation begins for a connection, 
the connection is initially enabled or disabled for 
list processing, depending on the setting of the 
reserved symbol LSTDIS in the LST/HDX/R supervisory 
message shown in figure 3-23. If LSTDIS is set to 
zero, then the connection is initially enabled for 
list processing via NETGETL or NETGTFL calls. When 
such a call returns a block of application block 
type 2 or 7 (identifying the last block of an upline 
message), NETGETL or NETGTFL calls disable the con¬ 
nection for subsequent list processing. 

Use of the turn-on—half-duplex-list-processing 
message has no effect on use of the turn-list¬ 
processing-off or turn-llst-processlng-on messages. 


The effects of the latter messages take precedence 
over the mode of duplexing operation in effect for 
a given connection. In addition, the turn-list- 
processing-on message enables the connection for 
input, even if no output has been sent. 
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ta 

Lst 

off 

res 

acn 


ta 


59 


51 49 


43 


35 


23 


1st 


off 


SymboLic address of the application program's text area from which this asynchronous super- 
visory message is sent. 

Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol LST. 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reverse symbol OFF. 

Reserved by CDC. Reserved fields contain zero. 

Application connection number assigned by the network software to the program end of the logi¬ 
cal connection for which list processing is being disabled. The value used in this field 
must be the value used in a CON/REQ/R message processed by the application program. You can 
access this field with the reserved symbol LSTACN, as described in section 4. 


Figure 3-20. Turn-List-Processing-Off (LST/OFF/R) Supervisory Message Format 


59 51 49 43 35 23 0 

1st 

0 

0 

on 

res 

acn 

res 


Symbolic address of the application program's text area from which this asynchronous super¬ 
visory message is sent. 

Primary function code CQi^_ You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol LST. 

on Secondary function code 1. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol ON. 

res Reserved by CDC. Reserved fields contain zero. 


acn Application connection number assigned by the network software to the program end of the logi¬ 

cal connection for which list processing is being enabled. The value used in this field must 
be the value used in a CON/REQ/R message processed by the application program. You can 
access this field with the reserved symbol LSTACN> as described in section 4. 


Figure.3-21. Turn-List-Processing-On (LST/ON/R) Supervisory Message Format 
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59 51 49 43 35 23 5 0 



ta Symbolic address of the application program's text area from which this asynchronous super¬ 

visory message is sent. 

1st Primary function code CO^^, You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol LST. 

swh Secondary function code 2. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol SWH. 

res Reserved by COC. Reserved fields contain zero. 

acn Application connection number assigned by the network software to the program end of the logi¬ 

cal connection being switched to a new connection List. The value used in this field must be 
the value used in a CON/REQ/R message processed by the application program. You can access 
this field with the reserved symbol LSTACN, as described in section 4. 

nualn The number of the new connection List to which the Logical connection is reassigned; 0 < 

nualn £ 63. You can access this field with the reserved symbol LSTALN, as described in 
section 4. 


Figure 3-22. Change-Connection-List (LST/SWH/R) Supervisory Message Format 


59 51 49 43 35 23 0 



ta Application program text area from which this asynchronous supervisory message is sent. 

1st Primary funtion code C0-]^_ You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol LST. 

hdx Secondary function code 4. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol HDX. 

res Reserved by CDC. Reserved fields contain zero. 

acn Application connection number assigned by the network software to the program end of the Logi¬ 

cal connection for which half-duplex List processing is being enabled. The value used in 
this field can be either zero or the value used in a CON/REQ/R message processed by the 
application program. If acn is zero, all connections are enabled; if acn is nonzero, the 
specific connection is enabled. You can access this field with the reserved symbol LSTACN, 
as described in section 4. 

dis Disable flag. Set the value of this flag either to 1 if the connection is to be initially 

disabled for normal List processing or to 0 if the connection is to be initially enabled for 
list processing. You can access this field with the reserved symbol LSTDIS, as described in 
section 4. 

Figure 3-23. Turn-On-Half-DupLex-List-Processing (LST/HDX/R) Supervisory Message Format 
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An application program can change a single connec¬ 
tion back to full-duplex operation at any time 
during network access by issuing the asynchronous 
supervisory message shown in figure 3-24, with the 
appropriate application connection number included 
in the acn field. Alternatively, the program can 
change all existing and any future connections by 
issuing the same supervisory message with an acn 
field value of zero. There is no response to either 
form of this message. 

When full-duplex operation begins for a connection, 
the connection is initially enabled for list proc¬ 
essing via NETGETL or NETGTFL calls. The connection 
remains enabled until disabled by the previously 
described turn-list—processing-off supervisory mes¬ 
sage. Upline delivery of a data block of applica¬ 
tion block type 2 or 7 has no relationship to down¬ 
line transmission of a block of the same block type. 

Use of the turn-on-full-duplex-list-processing mes¬ 
sage has no effect on use of the turn-llst- 
processing-off or turn-llst-processlng-on mes¬ 
sages, The effects of the latter messages take 
precedence over the mode of duplexing operation in 
effect for a given connection. If a given connec¬ 
tion has been disabled for any list processing by a 
turn-llst-processing-off message, it remains dis¬ 
abled after full-duplex operation is turned on for 
the connection. 

If either of the list duplexing control messages is 
issued for a connection already operating in the 
requested duplexing mode, the extra message is 
ignored. If the acn field specified within either 
message identifies a nonexistent logical connec¬ 
tion, a logical-error supervisory message is sent 
to the application program and the requested change 
in duplexing operation does not occur.- 


If either of the list duplexing control messages is 
issued with an acn field value of zero, the duplex¬ 
ing mode of application connection zero remains 
unchanged. The asynchronous supervisory message 
connection is always enabled for full-duplex opera¬ 
tion on application list zero. 


CONTROLLING DATA FLOW 

Data to and from console connections has its flow 
controlled at both ends of those connections. 
Whenever possible, this control is imposed volun¬ 
tarily by the application program. Conditions out¬ 
side the network, however, can interfere with data 
flow. Flow control is therefore also imposed by the 
network software in reaction to external conditions. 
When the latter occurs, the application program 
must compensate for the effect on data flow. 

Because the application program is not directly 
involved in the data exchange on batch device con¬ 
nections, the remaining paragraphs in this sub¬ 
section do not apply to appllcatlon-to-batch device 
connections. 

Downline flow control is logically separated from 
upline flow control. This separates flow control 
into an input function and an output function. 

Downline flow control is implemented through block 
delivery monitoring mechanisms. These mechanisms 
involve exchanges of asynchronous supervisory mes¬ 
sages, and the application program's adherence to 
data block transmission conventions. 

Upline flow is controlled by synchronous supervisory 
messages and by the application program's adherence 
to data block transmission conventions. 


59 

51 


49 

43 

35 

23 0 

Lst 

0 

0 

fdx 

res 

acn 

res 


ta 

Lst 


fdx 


res 


Application program text area from which this asynchronous supervisory message is sent. 

Primary function code You gan access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol LST. 

Secondary function code 3. You can access this field with the reserved symbol SFC, as 
described in section 4, Its value is defined as the value of the reserved symbol FDX. 

Reserved by CDC. Reserved fields contain zero. 


Application connection number assigned by the network software to the program end of the logi¬ 
cal connection for which full-duplex list processing is being enabled. The value used in 
this field can be either zero or the value used in a CON/REQ/R message processed by the 
application program. If acn is zero, all connections are enabled; if acn is nonzero, the 
specified connection is enabled. You can access this field with the reserved symbol LSTACN, 
as described in section 4. 


Figure 3-24, Turn-On-Full-Duplex-List-Processing CLST/FDX/R) Supervisory Message Format 
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MONITORING DOWNLINE DATA 

An application program can send downline blocks 
along a particular connection much faster than they 
can be output at a device or delivered to another 
application. Since NAM and CCP must save these 
extra blocks until they are processed by the other 
end of the connection, the extra blocks can cause 
NAM and CCP to have storage problems. On the other 
hand, the same application program might be sending 
blocks along another connection at such a slow rate 
that the other end of the connection is under¬ 
occupied. Network software provides a set of con¬ 
ventions that allow the application to control the 
flow of data between itself and its connections for 
increased efficiency in such cases. 

A block limit is established for each logical con¬ 
nection; this parameter indicates how many blocks 
of data or synchronous supervisory messages an 
application program can have outstanding on the 
logical connection at any instant. This block limit 
is the abl field value included in the connection 
request supervisory message. As blocks queue for 
delivery to the device or application, a block- 
delivered asynchronous supervisory message (figure 
3-25) is returned to the application. If the 
application program's output exceeds the value of 
the block limit, a logical-error asynchronous 
supervisory message is returned to the application, 
together with the reason for the error, and the 
last block is discarded by NAM. 

The block-delivered supervisory message is used to 
manage flow control; however, receipt of a block- 
delivered supervisory message does not in all cases 
guarantee that the data block has reached its des¬ 
tination. If the communication line, for example, 
fails before a block is completely output on a 
terminal device, the application program might 
still receive a block-delivered message. 


If the application program's output does not exceed 
the block limit, but for some reason a block is 
lost or unaccounted for, a block-not-delivered 
asynchronous supervisory message (figure 3-26) is 
returned to the application. Neither the block- 
delivered message nor the block-not-delivered mes¬ 
sage requires the application program to issue a 
response or acknowledgment message to NAM. 

This protocol allows the application to control 
downline data flow, as follows; 

Define two arrays, K and M. 

When a connection 1 Is accepted, set K(i)=0 and 
M(i)=block limit. 

Whenever a block-delivered message is received 
for application connection number i, set K(i)= 
K(i)-1. 

When a break supervisory message is received 
for an appllcatlon-to-appllcatlon connection, 
set K(i)=0. 

When a user-break caused user-interrupt super¬ 
visory message is received for a devlce-to- 
appllcatlon connection, do not set K(1)=0; 
block-delivered messages make this unnecessary. 

As long as K(l) is less than M(l), set K(i) = 
K(i)+1 and output one block on connection i. 


The break and user-break caused user-interrupt 
supervisory messages included in this strategy 
affect downline traffic on a logical connection. 
(The break message also affects upline traffic.) 
Such messages are sent to the application program 
whenever a network condition requires downline 
transmission on the connection to be Interrupted. 


59 

51 

49 

43 

35 

23 

5 0 

fc 

0 

0 

ack 

res 

acn 

abn 

res 


ta 

f c 

ack 

res 

acn 


Symbolic address of the application program’s text area receiving this asynchronous super¬ 
visory message. 

Primary function code 83-]^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol FC. 

Secondary function code 2. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol ACK. 

Reserved by CDC. 

Application connection number assigned by the network software to the program end of the logi¬ 
cal connection on which the block was delivered. This value is always nonzero and is the acn 
value used by the program in the application block header sent with the delivered block. You 
can access this field with the reserved symbol FCACN, as described in section 4. 


abn Application block number assigned by the application program to the delivered block. This 

value is the abn value used by the program in the application block header sent with the 
delivered block. You can access this field with the reserved symbol FCABN, as described in 
section 4. 


Figure 3-25. Block-Delivered CFC/ACK/R) Supervisory Message Format 


3-36 


60499500 T 




59 

51 

49 

43 

35 

23 

5 0 

fc 

0 

0 

nak 

rc 

acn 

abn 

res 


ta SyraboLic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

Primary function code 83.]^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol FC. 

nak Secondary function code 3. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol NAK. 

re Reason code explaining why the block was not delivered. This field can have the values: 

0 Reserved for COC use. 

1 Network software error caused no acknowledgment to be received by NAM from the 
network for the block. Either the block itself or its acknowledgnent was lost. 

The block can be retransmitted but will be delivered out of sequence with 
subsequently transmitted blocks and possibly duplicated. 

2 Reserved for CDC use. 
thru 

255 

You can access this field with the reserved symbol RC, as described in section 4. 

acn Application connection number assigned by the network software to the program end of the logi¬ 

cal connection on which the block was lost. This value is always nonzero and is the acn 
value used by the program in the application block header sent with the lost block. You can 
access this field with the reserved symbol FCACN, as described in section 4. 

abn Application block number assigned by the application program to the lost block. This value 

is the abn value used by the program in the application block header sent with the lost 
block. You can access this field with the reserved symbol FCABN, as described in section 4. 

res Reserved by CDC. 


Figure 3-26. Block-Not-Delivered (FC/NAK/R) Supervisory Message Format 


The NPU relies on the application program to decide 
when traffic can be resumed. Two sequences of 
events are possible when such interruptions occur. 
The sequence that occurs depends on whether the 
connection involved is with another application 
program or with a terminal device. 

For appllcatlon-to-appllcatlon connections, the 
following happens (see figure 3-27): 

1. Blocks sent downline- by your application pro¬ 
gram but not yet delivered to the other appli¬ 
cation are discarded. 

2. Blocks sent upline to your application program 
but not yet delivered from the other application 
program are discarded. 

3. An asynchronous break supervisory message 
(figure 3-28) is sent to your application 
program. If the connection uses an X.25 com¬ 
munication line, the side of the X.25 network 
originating the break is indicated by a reason 
code in the message. 

4. Your application program resets its flow control 
algorithm, as described previously in this sub¬ 
section. 


5. Your application program issues an asynchronous 
reset supervisory message, as shown in figure 
3-29, as a response to the break message. Until 
the reset message is sent, no upline or downline 
data can be exchanged on the connection, NAM 
sends no response to your reset message. 

6. Normal downline (and upline) traffic can now 
resume. The first block sent or received on 
the connection that is not a null block marks 
the point in traffic where data flow was Inter¬ 
rupted. 


For devlce-to-appllcatlon connections, the following 
happens (see figure 3-30): 

1. Blocks sent downline by your application program 
but not yet delivered to the device are dis¬ 
carded. Discarded blocks are acknowledged as 
delivered by NAM. 

2. NAM sends an asynchronous user-interrupt super¬ 
visory message with a reason code indicating a 
user-caused break (figure 3-31) to your appli¬ 
cation program. 
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Application NAM Message 

- FC/BRK/R 


The network software discards all unacknowl¬ 
edged blocks queued for delivery to the other 
application. 

-► FC/RST/R 

The application program can now resume communi¬ 
cation with the other application. 


Figure 3-27. Application-to-Application 
Connection Break and Reset 
Message Sequence 


3. NAM queues a synchronous break-indication-marker 
supervisory message (figure 3-32) after any data 
blocks not yet delivered to your application 
program. 

4. Your application program Issues an asynchronous 
interrupt-response supervisory message, as 
shown in figure 3-33, as a response to the 
user-lnterrupt message. Until this response 
message is sent, additional user-interrupt 
conditions involving the device are ignored. 
NAM sends no response to your user-interrupt- 
response message. 

5. Your application program processes all pending 
input on that connection by issuing NETGET or 
NETGETF calls (section 5) until the hreak- 
indlcation-marker message is received. The 
disposition of received data blocks is up to 
your application program. 


59 

51 

49 

43 

35 

23 0 

f c 

0 

0 

brk 

rc 

acn 

reserved 


ta 


f c 


brk 


re 


acn 


reserved 


Symbolic address of the application program's text area receiving this asynchronous supei— 
visory message. 

Primary function code 83-1^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol FC. 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol BRK. 

Reason code, explaining the cause of the break condition. This field is nonzero in upline 
messages for X.25 connections only. This field can contain the values: 

1 Reserved for CDC use. 

thru 

4 

5 A data communications equipment (DCE) break indicator (reset indication packet) 
occurred for the X.25 communication line used by the connection. 

6 A data terminal equipment (DTE) break indicator (reset indication packet) 
occurred for the X.25 communication line used by the connection. 

8 Reserved for CDC use. 

thru 

191 

192 Reserved for site-defined use. 

thru 

255 

You can access this field with the reserved symbol FCRBR, as described in section 4. 

Application connection number assigned by the network software to the program end of the logi¬ 
cal connection on which the break occurred. This field always contains a nonzero value 
previously used by the application program in an FC/INIT/N message and must be used by the 
application program in a subsequent FC/RST/R message before data transmission on the 
connection is again possible. You can access this field with the reserved symbol FCACN, as 
described in section 4. 

Reserved for CDC. Reserved fields must be equal to zero. 


Figure 3-28. Break (FC/BRK/R) Supervisory Message Format 
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51 49 43 35 


fc 00 rst reserved 


reserved 


Symbolic address of the application program's text area from which this asynchronous super¬ 
visory message is sent. 

Primary function code 8316. can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol FC. 

Secondary function code 1. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol RST. 

Application connection number assigned by the network software to the program end of the logi¬ 
cal connection to be reset. This value is always nonzero and must be the acn value received 
by the application program in a previous FC/BRK/R message. You can access this field with 
the reserved symbol FCACN, as described in section 4. 


Figure 3-29. Reset (FC/RST/R) Supervisory Message Format 


Application 


Message 


INTR/USR/R 


Connection 


The network software acknowledges and discards all blocks queued for delivery to the 
device. Your application program can request queued input from NAM but cannot receive 
another INTR/USR/R affecting this connection. 

The program requests all queued input from NAM. The network software continues to 
discard and acknowledge downline blocks. 

- BI/MARK/R Nonzero 


INTR/RSP/R 

RO/MARK/R 


Nonzero 


Your application program can now resume output to the device. NAM stops discarding 
downline blocks. 


Figure 3-30. Terminal User-Caused Break Sequence 
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ta 

intr 

usr 

rc 


acn 

res 


59 


51 49 


43 


35 


23 


ta 


intr 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message or from which this message is sent. 

Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. The value of this field is defined as the value of reserved symbol 
INTR. 

Secondary function code 00. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol USR. 

Reason code, explaining the cause of the interrupt condition. This field can contain the 
values: 

0 Valid on application-to-application connections only; no predefined meaning. 

thru 

2 

3 On device-to-application connections, the terminal operator used the key or 
entered the character defined for the device as generating a user-break-1 
condition; discard all blocks received until a BI/MARK/R synchronous supervisory 
message is received. On application-to-application connections, no predefined 
meaning. 

4 On device-to-application connections, the terminal operator entered the character 
defined for the device as generating ,a user-break-2 condition; discard all blocks 
received until a BI/MARK/R synchronous supervisory message is received. On 
application-to-application connections, no predefined meaning. 

5 On device-to-application connections, refer to figure 3-39. On 

thru application-to-application connections, no predefined meaning. 

255 

Application connection number assigned by the network software for the connection sending the 
user-interrupt request. You can access this field with the reserved symbol INTRACN, as 
described in section 4. 

Reserved by CDC. 


Figure 3-31. User-Interrupt (INTR/USR/R) Supervisory Message Format 
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ta 


59 


51 

49 


43 



0 

bi 

0 

0 

mark 

res 

59 

55 



47 

43 

41 

35 

0 

0 

bi 

0 

0 

0 

mark 

res 


act=2 


act=3 


ta 

bi 

mark 

res 


Symbolic address of the application program's text area receiving this synchronous super¬ 
visory message. 

Primary function code CA^^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol BI. 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol HARK. 

Reserved by CDC. 


Figure 3-32. Break-Indication-Harker CBI/HARK/R) Supervisory Hessage Format 


59 

51 


49 

43 

35 

23 0 

intr 

0 
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Symbolic address of the application program’s text area from which this asynchronous super¬ 
visory message is sent. 

Primary function code 80^g_ You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol INTR. 

Secondary function code 01. You can access this field with the reserved symbol SFC, as 

defined in section 4. Its value is defined as the value of the reserved symbol RSP. 

Application connection number assigned by the network software for the connection on which 
the user-interrupt-response supervisory message was sent. The value placed in this field 
must be the device connection value used in the INTR/USR/R message to which this message is 

a response. You can access this field with the reserved symbol INTRACN, as described in 

section 4. 

Reserved by COC. Reserved fields contain zero. 


F.igure 3-33. -Application-Interrupt-Response CINTR/RSP/R) Supervisory Hessage Format 
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6. Your application program Issues a synchronous 
resume-output-marker supervisory message (figure 
3-34), as a response to the break-indication- 
marker message. Until this message is sent, 
downline data sent on the connection is dis¬ 
carded by the network. NAM sends no response 
to your resume-output-marker message. Normal- 
downline traffic can now resume. 

If your application program does not complete one 
of these sequences properly, it receives an asyn¬ 
chronous logical-error supervisory message. The 
logical-error message is described at the end of 
section 3. 

The user-interrupt message reflects suspension of 
downline traffic only. Upline traffic (input) on 
the connection is not affected. 

CONTROLLING OR BYPASSING 
UPLINE AND DOWNLINE DATA 

Several asynchronous supervisory messages allow your 
application program to: 

Control the flow of upline and downline data to 
both ends of an applicatlon-to-appllcation con¬ 
nection. 

Control the flow of downline data on a devlce- 
to-appllcation connection. 

Bypass data blocks or synchronous supervisory 
messages on an appllcation-to-appllcation con¬ 
nection; this allows your application program 
to control the flow of downline data on an 
appllcatlon-to-appllcation connection if both 
programs recognize a method of doing so. 

The sequences and forms of the messages used depend 
on whether the connection is with another applica¬ 
tion program or with a terminal device. 


Discarding Upline and Downline Data on 
Application-to-Application Connections 

Your program can discard all upline and downline 
data queued between itself and another application 
program by sending the asynchronous break super¬ 
visory message shown in figure 3-28. NAM does not 
send a response for this message to your program. 

The rest of the steps shown in figure 3-27 then 
occur: 

1. Blocks sent downline by each application program 
but not yet delivered to the other application 
are discarded. 

2. Blocks sent upline to each application program 
but not yet delivered from the other application 
program are discarded. 

3. An asynchronous break supervisory message 
(figure 3-28) is sent to the other application 
program. 

4. Each application program resets its flow con¬ 
trol algorithm, as described previously under 
Monitoring Downline Data. 

5. The other (receiving) application program issues 
an asynchronous reset supervisory message, as 
shown in figure 3-29, Until the reset message 
is sent, no upline or downline data can be 
exchanged on the connection. NAM sends no 
response to either reset message. 

6. Normal downline and upline traffic can now 
resume. The first block sent or received on 
the connection that is not a null block marks 
the point in traffic where data flow was inter¬ 
rupted. 
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59 55 47 43 41 35 0 

0 

ro 

0 

0 

0 

mark 

res 


act=2 


act=3 


ta 


mark 


Symbolic address of the application program's text area from which this synchronous super¬ 
visory message is sent. 

Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol RO. 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol MARK. 


Reserved by CDC. Reserved fields contain zero. 


Figure 3-34. Resurae-Output-Marker (RO/HARK/R) Supervisory Message Format 
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Discarding Downline Data on 
Device-to-Application Connections 

Your program can discard all downline data queued 
between Itself and a terminal device by sending the 
asynchronous appllcatlon-lnterrupt supervisory mes¬ 
sage shown In figure 3-35, using a parm field value 
of 2. 

The first set of steps shown In figure 3-36 then 
occurs: 

1. The network begins discarding downline blocks 
queued for delivery to the device. Upline 
blocks queued for delivery to your application 
program are not affected. 

2. Your application program sends a synchronous 
termlnate-output-marker supervisory message, as 
described In figure 3-37. This message Indi¬ 
cates to the network software the place in the 
downline data flow where it should stop dis¬ 
carding blocks. 

3. The network sends your application program an 
asynchronous interrupt-response supervisory 
message (figure 3-33). Until this message is 
received, your program cannot send another 
appllcatlon-lnterrupt message affecting the 
same connection. 

4. Normal downline data traffic can now resume. 


If your application program Issues another 
appllcatlon-lnterrupt message before receiving an 
interrupt-response message. It receives an asyn¬ 
chronous logical-error supervisory message. The 
logical-error message is described at the end of 
section 3. 

Discarding Upline and Downline Data on 
a Device-to-Application Connection 

Your application program can discard all upline and 
downline data queued between itself and a terminal 
device by sending the asynchronous break 
supervisory message shown in figure 3-28. 

The set of steps shown in figure 3-38 then occur: 

1. Blocks sent downline but not yet delivered to 
the terminal device are discarded. 

2. Blocks queued upline for the application 
program are discarded. Any partial upline 
input that had been entered at the terminal 
device is also discarded. Data that comes in 
from the terminal after the procesing of an 
FC/BRK/R message will go upline. 

3. Your application program should reset its flow 
control algorithm, as described previously 
under Monitoring Downline Data. 


59 51 49 43 35 23 . 0 

ta 

ta 

intr 

app 

parm 


intr 


app 


parm 


Symbolic address of the application program's text area from which this asynchronous super¬ 
visory message is sent. 

Primary function code 80-|6. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol INTR. 

Secondary function code 2. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol APP. 


AppIicat ion-interrupt 8-bit value. Can be one of the following: 


acn 


0 Valid on application-to-application connections only; no predefined meaning, 

and 
1 

2 On device-to-application connections, discard all blocks received until a 
TO/MARK/R synchronous supervisory message is received. On 
application-to-application connections, no predefined meaning. 

3 Valid on application-to-application connections only; no predefined meaning, 
thru 

255 

You can access this field with the reserved symbol INTRCHR, as described'in section 4. 


Application connection number assigned by the network software for the connection on which 
the application interrupt is requested. You can access this field with the reserved symbol 
INTRACN, as described in section 4. 


Figure 3-35. Application-Interrupt CINTR/APP/R) Supervisory Message Format 
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Symbolic address of the application program's text area from which this asynchronous super¬ 
visory message is sent or into which it is received. 

Primary function code 80^^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol INTR. 

Secondary function code 01. You can access this field with the reserved symbol SFC, as 

defined in section 4. Its value is defined as the value of the reserved symbol RSP. 

Application connection number assigned by the network software for the connection on which 
the user-interrupt-response supervisory message was sent. The value placed in this field 
must be the device connection value used in the INTR/USR/R message to which this message is 

a response. You can access this field with the reserved symbol INTRACN, as described in 

section 4. 

Reserved by CDC. Reserved fields contain zero. 


Figure 3-36. Application-Interrupt-Response (INTR/RSP/R) Supervisory Message Format 
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act=3 


ta Symbolic address of the application program's text area from which this synchronous super¬ 

visory message is sent. 

to Primary function code C4i^_ You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol TO. 

mark Secondary function code 0. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol MARK. 

res Reserved by CDC. 


Figure 3-37. Terminate-Output-Marker (TO/MARK/R) Supervisory Message Format 
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4. The network sends your application program an 
asynchronous reset supervisory message, as 
shown in figure 3-29. Until the reset message 
is received, no downline data should be sent on 
the connection. Such downline data will be 
discarded by NAM until it queues the reset 
message for your application program. 

5. Normal downline and upline traffic can now 
resume. 


Bypassing Downline Data on an 
Application-to-Application Connection 

Your program can bypass all downline data queued 
between itself and another application by sending 
the asynchronous application-interrupt supervisory 
message shown in figure 3-35, using any parm field 
value. NAM does not send a response for this 
message to your program. 

The second set of steps shown in figure 3-39 then 
occurs: 

1. The network does not discard any blocks queued 
for delivery to the other application program. 
Upline blocks from the other program queued for 
delivery to your application program are not 
affected. Neither program's flow control 
algorithm is affected. 

2. The network sends the other application program 
an asynchronous user-interrupt supervisory 
message (figure 3-31), containing a reason code 
equal to the parm value your program sent in 
its application-interrupt message. 

3. The other application program sends the network 
an asynchronous application-interrupt-response 
supervisory message (figure 3-33). If the 
other program recognizes the reason code as 
indicating the need to discard your program's 
downline (the other program's upline) - data 
blocks, it will begin to do so. 


Application 


Message 


Connection 


-► INTR/APP/R Zero 

The network acknowledges and discards all blocks queued for delivery to the device. 
Your application program can request queued input from NAM but cannot send another 
INTR/APP/R affecting this connection. 


TO/HARK/R 


Nonzero 


- INTR/RSP/R Zero 

Your application program can now resume output to the device. NAM stops discarding 
downline blocks. 


Application 1 NAM Application 2 Message 


Connection 


INTR/APP/R Zero 


INTR/USR/R Zero 


The other application program discards all blocks delivered to it, if that is an 
appropriate action for an interrupt. 


Your application program can now resume normal output. The other program stops 
discarding your downline blocks. 

- INTR/RSP/R Zero 

- INTR/RSP/R Zero 
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If your program does not use the application- 
interrupt message as a method of discarding data, 
the following step does not apply: 

4. Both programs now must recognize some marker in 
your program's downline data to indicate the 
point in the process where the other program 
should stop discarding blocks. The synchronous 

■ terminate-output-marker supervisory message, as 
described in figure 3-36, can be used. NAM 
sends no response to this message and does not 
interpret it. 

5. The other application program Issues an 

applicatlon-ln terrupt-response asynchronous 

supervisory message (figure 3-33). 

6. The network sends your application program an 

asynchronous nppl ication-lnterruptr-response 

supervisory message (figure 3-33). Until this 
message is received, your program cannot send 
another application-interrupt message affecting 
the same connection. 

7. Your program can now resume normal downline 
traffic. 


TERMINAL USE OF USER INTERRUPTS 
FOR PRIORITY DATA 

The terminal operator can send a message to the 
application that bypasses regular upline data by 
entering a user-Interrupt priority data sequence. 
The operator enters the sequence by entering the 
TIP command control character (defined by the CT 
command) and an alphabetic character. NAM generates 
the user—interrupt-request supervisory message, 
INTR/USR/R (Illustrated in figure 3-40) and sends 
it to the application. 


The application program responds with the 
application-interrupt-response supervisory message 
(Illustrated in figure 3-36) after receiving the 
INTR/USR/R message if the application supports user 
Interrupts. If the application does not support 
priority data user interrupts, it- can ignore the 
INTR/USR/R message and issues no response. Figure 
3-41 Illustrates the flow of messages.. Until the 
response is sent, the user cannot, enter another 
interrupt sequence. 


Application NAH Message 

- INTR/USR/R 

NAH delivers the user-interrupt ASCII char¬ 
acter to the application in an asynchronous 
supervisory message on acn=0. 

Supervisory programs and applications that do 
not support the usei—interrupt-request message 
need take no further action. 

-► INTR/RSP/R 

The application that supports user interrupt 
requests must respond with an application- 
interrupt-response supervisory message on 
acn=0. 


Figure 3-41. User Interrupt for Priority 
Data Supervisory Message Sequence 

If the application program supports priority data 
user interrupts, predefined meanings can be given 
to the ASCII characters available as Interrupt 
characters. Only the characters A through Z and a 
through z can be used. 
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intr 

0 

0 

usr 

char 

acn 

res 


ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 


intr 


usr 


char 


acn 


res 


Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. The value of this field is defined as the value of reserved symbol 
INTR. 

Secondary function code 00. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol USR. 

User-interrupt character. This 8-bit field contains one of the 7-bit ASCII codes for letters 
shown in table A-2. You can access this field with the reserved symbol INTRCHR, as described 
in section 4. 

Application connection number assigned by the network software for the connection sending the 
user-interrupt request. You can access this field with the reserved symbol INTRACN, as 
described in section 4. 

Reserved by CDC. 


Figure 3-40. User-Interrupt-Request (INTR/USR/R) Supervisory Message Format for Priority Data 
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CONTROLLING UPLINE BLOCK 
CONTENT 

Several asynchronous supervisory messages allow you 
to control the content of upline blocks. (Downline 
block content is controlled directly by your program 
and indirectly by the values your program places in 
the accompanying application block header.) Using 
supervisory messages, your program can: 

Convert character codes in unrecelved upline 
network data blocks to 6-bit display code or 
cancel such conversion 

Change character byte packing in unreceived 
upline network data blocks 

Change byte packing in unreceived synchronous 
supervisory message blocks 

Discard unrecelved transparent mode data from a 
device or cancel that discarding operation 

Truncate unrecelved upline blocks 

The following subsections describe these supervisory 
messages. 


CONVERTING AND REPACKING DATA 

Data exchanged on an interactive devlce-to- 
appllcation connection is converted to and from 
display code or ASCII character codes at the 
discretion of the application program. This 
conversion also Includes packing and unpacking of 
data character codes from bytes of different sizes. 
NAM converts data in a given block according to the 
application character type associated with the 
block. 

Data sent downline by an application program for 
output at an interactive device or to another 
application has an application character type 
associated with it on a block-by-block basis. When 
the application program needs to change the conver¬ 
sion performed for downline data on a given con¬ 
nection, it simply^changes the act field value used 
in the block header of each data block. The effects 
of a given act field value declaration are described 
in detail in section 2, 

Upline data from a console device or another appli¬ 
cation has an application character type associated 
with the logical connection on which the data blocks 
are received. The application character type 
associated with the connection is assigned by the 
application program when the logical connection is 
first established. This assignment is part of the 
connection-accepted supervisory message. 


When the application program needs to change the 
conversion performed for upline data on a given 
connection, it changes the act field value 
associated with the logical connection by issuing 
the asynchronous change-input-character-type super¬ 
visory message. This message can be Issued at any 
time the logical connection exists, after the 
application program has issued the FC/INIT/N mes¬ 
sage for the connection. As shown in figure 3-42, 
there is no response to the change-lnput- 


character-type message, 
effect immediately. 

but the 

message takes 

Application 

NAM 

Message 



DC/CICT/R 



The next input request 
nection returns blocks 
character type. 

for this 
in bytes 

logical con- 
of the new 


Figure 3-42. Change-Input-Character- 
Type Supervisory Message Sequence 


The change-input-character-type message has the 
format shown in figure 3-43. The act field values 
described in the figure are explained in more 
detail in section 2. Note that transparent mode 
upline data cannot be correctly received when an 
application character type other than 2 or 3 is 
associated with the logical connection. 

The conversion change requested by the change-input- 
character-type message affects the next block 
fetched by the application program. For example, 
the application program might have been receiving 
blocks of 7-bit ASCII code characters, packed in 
12-blt bytes (an act value of 3); the application 
program now needs to receive blocks of 6-bit display 
code characters, packed in 6-bit bytes (an act value 
of 4). The program sends a change-input-character- 
type message, , specifying an act value of 4; the 
next block received from that logical connection is 
6-bit display code characters, packed in 6-blt 
bytes. 


If the requested application character type is not 
valid for the connection specified, a logical-error 
supervisory message is sent to the application pro¬ 
gram, and the application character type associated 
with the logical connection is unchanged. Other¬ 
wise, receipt of the change-input-character-type 
message Is not acknowledged. 
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ta Symbolic address of the application program's text-area from which this asynchronous super¬ 

visory message is sent. 

dc Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol DC. 

cict Secondary function code 0. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CICT. 

res Reserved by CDC. Reserved fields contain zero. 

acn Application connection number assigned by the network software to this end of the logical 

connection when it was established. The value placed in this field must be the value 
associated with an existing connection and used in the FC/INIT/N supervisory message that 
completed initialization of the connection. You can access this field with the reserved 
symbol DCACN, as described in section 4. 

nxp No-transparent-input flag. This field can have the values: 

0 Deliver network data blocks with the xpt bit set in the associated block header 

1 Do not deliver network data blocks with the xpt bit set in the associated block 

header 

You can access this field with the reserved symbol OCNXP, as described in section 4. 

set Application character type in which the application program expects to receive synchronous 

supervisory messages. This field can have the values: 

0 Deliver supervisory messages in application character type 2 

1 Deliver supervisory messages in application character type 3 

You can access this field with the reserved symbol DCSCT, as described in section 4. 


Figure 3-43. Change-Input-Character-Type (DC/CICT/R) Supervisory Message Format (Sheet 1 of 2) 
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act 

Application character type, specifying the form of character byte packing that the 
application program requires for all future input data blocks from the logical connection. 

The value declared replaces the value previously declared by the application program for this 
connection in a CON/REQ/N or DC/CICT/R message. This field can have the values: 


0 

or 

1 

2 

Reserved for CDC use. 


8-bit characters in 8-bit bytes, packed 7.5 characters per central memory word; 
if the input is not transparent mode, the ASCII character set described in table 

A-2 is used. 


3 

8-bit characters in 12-bit bytes, packed 5 characters per central memory word, 
right-justified with zero fill within each byte; if the input is not transparent 
mode, the.ASCII character set described in table A-2 is used. 


4 

6-bit display code characters in 6-bit bytes, packed 10 characters per central 
memory word; the characters used are the ASCII set of CDC characters described in 
table A-1. This applies to terminal-to-application connections only. 


5 

thru 

11 

Reserved for CDC use. 


12 

thru 

15 

Reserved for installation use. 


The act value declared applies only to input on the connection and can be changed by another 
DC/CICT/R message at any time during the existence of this logical connection.' You can 
access this field with the reserved symbol CONACT, as described in section 4. 


Figure 3-43. Change-Input-Character-Type (DC/CICT/R) Supervisory Message Format (Sheet 2 of 2) 


REPACKING SYNCHRONOUS SUPERVISORY 
MESSAGE BLOCKS 

Synchronous supervisory message block fields are 
packed in either 8-bit or 12-bit bytes, at the 
discretion of the application program. NAM packs 
or unpacks fields in a given synchronous supervisory 
message block according to the application character 
type associated with the block (downline) or with 
the connection (upline). 

Synchronous supervisory messages sent downline by 
an application program have an application character 
type associated with them on a block-by-block basis. 
When the application program needs to change the 
packing performed for blocks on a given connection, 
it simply changes the act field value used in the 
block header of each synchronous supervisory mes¬ 
sage. The effects of a given act field value 
declaration are described in detail in section 2, 

An upline synchronous supervisory message block has 
an application character type associated with the 
connection on which' the block is received. The 
application character type associated with the 
connection is assigned by the application program 
as the set field value when the connection is first 
established. This assignment is part of the 
connection-accepted supervisory message and is 
separate from the assignment made' for data blocks 
received on the connection. 


When the application program needs to change the 
packing performed for upline synchronous supervisory 
messages on a given connection, it changes the set 
field value associated with the connection by 
issuing the asynchronous change-input-character-type 
supervisory message. This message can be issued at 
any time the logical connection exists, after the 
application program has issued the FC/INIT/N message 
for the connection. As shown in figure 3-42, there 
is no response to the change-input-character-type 
supervisory message, but the message takes effect 
immediately. 

The change-input-character-type message has the 
format shown in figure 3-43. The application 
character types selected with the set field values 
are described in more detail in section 2. 

The repacking change requested hy the change-input- 
character-type message affects the next block 
fetched by the application program. For example, 
the application program might have been receiving 
synchronous supervisory messages with fields packed 
in 12-bit bytes (using an application character 
type of 3); the application program now needs to 
receive synchronous supervisory message blocks with 
fields stored in 8-bit bytes (using an application 
character type of 2). The program sends a change- 
input-character-type message, specifying an set 
field value of 0; the next synchronous supervisory 
message block received on that logical connection 
is packed in 8-blt bytes. 
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EXCHANGING TRANSPARENT DATA WITH 
DEVICES 

Transparent data is exchanged with a terminal device 
at the discretion of the application program. NAM 
transfers transparent data blocks according to the 
transparent data flag associated with the block. 

Network data blocks sent downline by an application 
program have a transparent data flag associated 
with them on a block-by-block basis. When the 
application program needs to change from or to 
transparent mode output on a given connection, it 
simply changes the xpt field value ' used in the 
application block header of each downline data 
block. The effects of a given xpt field value are 
described in detail in section 2. 


Upline network data blocks also have a transparent 
data flag associated with them on a block-by-block 
basis. Each connection has a no-transparent-data 
flag associated with that connection. This flag 
indicates whether the application wants to receive 
transparent data or wants NAM to discard such data. 
The no transparent-data flag setting associated 
with the connection is assigned by the application 
program as the nxp field value when the connection 
is first established. This assignment is part of 
the connection-accepted supervisory message. 


When the application program needs to change the 
value of the no-transparent-data flag for a given 
connection, it issues the change-input-character— 
type synchronous supervisory message. This message 
can be issued at any time the logical connection 
exists, after the application program has Issued 
the FC/INIT/N message for the connection. As shown 
in figure 3-42, there is no response to the change- 
input -character-type message, but the message takes 
effect immediately. 


The change-input-character-type message has the 
format shown in figure 3-43. The effects of the 
nxp field values used in the message are described 
in section 2, where the application block header 
fields are described. 


The transparent data exchange change requested by 
the change-input-character-type message affects the 
next upline block and all subsequent blocks queued 
for the application program. For example, the 
application program might have been receiving 
transparent blocks for an interactive console when 
the program contains no code to process those 
blocks; it needs to prevent receipt of any more 
transparent blocks while that connection exists. 
The program sends a change-input-character-type 
message, specifying an nxp field value of 1; the 
next (and any subsequent) block from that terminal 
device is discarded if it is in transparent mode, 
even if that block completes the current message. 


The setting of the no-transparent-input flag does 
not cause data blocks on application-to-appllcation 
connections to be discarded, unless the sending 
application program sets the xpt field value of the 
associated block header to 1. 


TRUNCATING UPLINE BLOCKS 

Blocks received upline by an application program 
from a terminal or from another application can be 
truncated to fit the text area buffer provided by 
your application. This truncation allows the 
application to obtain at least part of a block 
longer than the text area instead of receiving an 
Input-block-undeliverable reply (Ibu bit set in the 
block header). An asynchronous supervisory message 
can be used to inform NAM that the application 
wants to have a block truncated on a particular 
connection or to have blocks truncated on all 
existing and future connections. As indicated in 
figure 3-44, the effect of this supervisory message 
cannot be reversed, and there is no response. 



Figure 3-44. Block Truncation 
Supervisory Message Sequence 


When a block is truncated, the tru bit in the 
application block header is set, and the tic field 
in the block header is set to the size of the 
portion of the block received (Instead of being set 
to the full size of the block). 


This block truncation supervisory message (figure 
3-45) can be Issued at any time after completion of 
a NETON call. This message affects all messages on 
the connection, including synchronous supervisory 
messages. If acn=0 is specified, the application 
has to call NETOFF and NETON again to not receive 
truncated data blocks. 

If the acn field specified within the message 
identifies a nonexistent logical connection, a 
logical—error supervisory message is sent to the 
application and data truncation does not occur. If 
more than one data truncation message affecting a 
connection is Issued, the extra messages are 
ignored. 


3-50 


60499500 T 




ta 


59 


51 49 


43 


35 


23 


dc 


tru 


ta 

dc 

tru 

res 


Application program text area from which this asynchronous supervisory message is sent. 

Primary function code C2^^_ You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol DC. 

Secondary function code Ol-j^, You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol TRU. 

Reserved by CDC. Reserved fields contain zero. 


acn Application connection number. If zero, all existing and future connections other than 

connection zero will have truncation control on. If acn is not zero, truncation control 
will be on for that connection only. You can access this field with the reserved symbol 
DCACN, as described in section 4. 


Figure 3-45. Block Truncation 


MANAGING CCP DEVICE 
CHARACTERISTICS 

Devices serviced as interactive virtual terminals 
have many characteristics that can affect the way 
in which they send or output data. The network 
software can use varying numbers of these charac¬ 
teristics, depending on the terminal class of the 
device and sometimes on the protocol used by the 
device. 

The following characteristics can be known and used 
through the network software when servicing an 
asynchronous device in terminal classes 1 through 
8, or any device in terminal classes 28 through 31: 

Character used to discard a block of output 

Whether the break key should be Interpreted as 
a cancel input and user break 1 command (does 
not apply to terminal class 4) 

Backspace character used to edit a line of data 

Characters used as user break 1 and user break 
2 commands 

Enable recognition of the user-break-1 and 
user-break-2 characters while in transparent 
input mode 

Number of idle characters needed after a car¬ 
riage return or a line feed 

Character used to cancel an input line 

Cursor positioning needed at the end of a 
physcial line or block (does not apply to 
terminal class 4) 

Network control character used 

Delimiters of single-message transparent input 
(does not apply to terminal class 4) 

Delimiters of multiple-message transparent input 
(does not apply to terminal class 4) 


(DC/TRU/R) Supervisory Message Format 


Number of milliseconds delay needed after a 
carriage return or a line feed 

Whether solicited input mode is to be in effect 
(application program must send the last block 
of a message to a device or input is discarded) 

Character used at the end of a logical input 
line or of an input block (does not apply to 
terminal class 4) 

Echoplex mode (does not apply to terminal class 

4 ) 

Whether full-ASCII or special editing mode is 
in use 

Whether the device supports input or output flow 
control characters- (does not apply to terminal 
class 4) 

Whether the device is using paper tape, a key¬ 
board, block mode, or transparent mode during 
input (does not apply to terminal class 4) 

Whether the device is using a display, a 
printer, or paper tape during output (paper 
tape does not apply to terminal class 4) 

The parity processing required during input and 
output (does not apply to terminal class 4) 

What the page width and page length are 

Whether page waiting occurs 

Whether unsolicited messages from the network 
operator can be delivered 

What the terminal class is 

Whether the communication line is serviced in 
full-duplex mode (does not apply to terminal 
class 4) 

What the upline blocking factor is 
What the transmission block size is 
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The following characteristics can be known and used 
through the network software when servicing an X.25 
device in terminal classes 1 through 3 or 5 through 
8: 

Whether the break key should be interpreted as 
a user break 1 command 

Backspace character used to edit a line of data 

Characters used as user break 1 and user break 
2 commands 

Enable recognition of the user-break-1 and 
user-break-2 characters while in transparent 
input mode 

Number of idle characters needed after a cai^ 
rlage return or a line feed 

Number of milliseconds delay needed after a 
carriage return or line feed 

Character used to cancel an input line 

Cursor positioning needed at the end of a 
physical line or block 

Network control character used 

Whether solicited input mode is to be in effect 

Delimiters of single-message transparent input 

Delimiters of multiple-message transparent input 

Character used at the end of a logical input 
line or of an input block 

Whether full-ASCII or special editing mode is 
in use 

Echoplex mode 

Whether the device supports input or output 
flow control characters 

Whether the device is using a display, a 
printer, or paper tape during output 

The parity processing required during output 

What the page width and page length are 

Whether page waiting occurs 

Whether unsolicited messages from the network 
operator can be delivered 

What the terminal class is 

Whether the communication line is serviced in 
full-duplex mode (does not apply to terminal 
class 4) 

What the upline blocking factor is 

What the transmission block size is 

The following characteristics can be known and used 
through the network software when servicing a CDC 
mode 4 device in terminal classes 10 through 13 or 
15: 

Characters used as user break 1 and user break 
2 commands 


Enable recognition of the user-break-1 and 
user-bredk-2 characters while in transparent 
input mode 

Character used to cancel an input line 

Network control character used 

Delimiters of single-message transparent input 

Delimiters of multiple-message transparent input 

Character used at the end of a logical input 
line or of an input block 

Whether solicited input mode is to be in effect 

Whether full-ASCII editing mode, is in use 

Whether the device is using block mode or 
transparent mode during input 

What the page width and page length are 

Whether page waiting occurs 

Whether unsolicited messages from the network 
operator can be delivered 

What the terminal class is 

What file upline blocking factor is 

What the terminal transmission block size is 

The following characteristics can be known and used 
through the network software when servicing a HASP 
device in terminal classes 9 or 14: 

Characters used as user break 1 and user break 
2 commands 

Character used to cancel an input line 

Network control character used 

Whether solicited input mode is to be in effect 

Character used at the end of a logical input 
line 

What the page width and page length are 
Whether page waiting occurs 

Whether unsolicited messages from the network 
operator can be delivered 

What the terminal class is 

What the upline blocking factor is 

What the terminal transmission block size is 

The following characteristics can be known and used 
by the network software when servicing a 2780 or 
3780 device in terminal classes 16 or 17: 

Network control character used 

What the page width and page length are, 

Whether page waiting occurs 

Whether unsolicited messages from the network 
operator can be delivered 
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What the terminal class is 

What the upline blocking factor is 

What the terminal transmission block size is 


The following characteristics can be known and used 
through the network software when servicing a 3270 
device in terminal class 18: 

Characters used as user break 1 and user break 
2 commands 

Character used to cancel an input line 
Network control character used 

Character used at the end of a logical input 
line 

Whether solicited input mode is to be in effect 
What the page width and page length are 
Whether page waiting occurs 

Whether unsolicited messages from the network 
operator can be delivered 

What the terminal class is 

What the upline blocking factor is 

What the terminal transmission block size is 


Your application program can determine these 
characteristics or change them by using the super¬ 
visory messages described in the next subsections. 
Information on the use of these characteristics 
appears in the NAM 1/CCP 3 Terminal Interfaces 
reference manual listed In the preface. 


CHANGING CCP DEVICE 
CHARACTERISTICS 

The process of configuring a terminal consists of 
defining a number of device characteristics that 
the network software should use in communication 
with a terminal. Some device characteristics can 
be given default values by the Communications 
Control Program (CCP), while others can be provided 
by the Network Definition Language (NDL) and the 
site administrator. 

Once a device is configured (or defined) , sub¬ 
sequent changes to the device definition can be 
made via terminal definition commands from the 
terminal operator, or via supervisory messages from 
the application program to which the device is 
connected. 

This subsection describes the supervisory messages 
that the application can use to change the settings 
of device characteristics. The supervisory message 
used to find out the current values of device 
characteristics is described in the following sub¬ 
section, Requesting Device Characteristics. Ter¬ 
minal definition commands are described in the NAM 
1/CCP 3 Terminal Interfaces reference manual listed 
in the preface. 


Figure 3-46 shows the most probable message 
sequences involved in changing terminal character¬ 
istics. 

The application program is advised of the terminal 
definition command entry explicitly only when the 
command changes one of three device characteristics: 

Terminal class (value describing the physical 

attributes of a group of similar terminals) 

Page width (value describing the number of 

characters in each physical line of output) 

Page length (value describing the number of 

physical lines output per page) 

The upline device-characteristics-redefined super¬ 
visory message Is an asynchronous one, with the 
format shown in figure 3-47. This message is sent 
to the application by NAM whenever NAM is notified 
that one of the three device characteristics has 
been redefined by a terminal user or by the applica¬ 
tion program. The effect of the terminal definition 
command causing this message is immediate, and no 
response is required from the application program. 

There are two different formats for changing 
terminal characteristics. Regardless of the format 
used, terminal class should only be changed before 
other changes are made. A change in terminal class 
resets many other characteristics. 

The deflne-device-characterlstlcs supervisory 

message (figure 3-48) specifies terminal charac¬ 
teristic commands as a string of ASCII characters. 
If there is an error in one of the commands, the 
TIP stops processing the message, no indication is 
sent to the application, and any commands prior to 
the error are , processed. There is no response to 
this message. The def ine-device-characterlstlcs 
supervisory .message is not supported by CDCNET. 

The define-mul tlple-devlce-characteristics message 
is described in figure 3-49. This message specifies 
a string of pairs of 8-bit numbers starting after 
the secondary function code field and extending for 
as many 8-bit bytes as necessary. The application 
stores an 8-bit field number (FN) in the first of a 
pair of bytes and a field value (FV) in the second 
byte of the pair. Each FN represents a particular 
device characteristic corresponding to a terminal 
definition command or command parameter, and the 
corresponding FV represents the value the applica¬ 
tion program wishes to assign to that character¬ 
istic. The application program needs to specify 
only the FN/FV pairs for the characteristic it wants 
to change. If one of the FN/FV pairs contains an 
incorrect value, no characteristics are changed and 
the application program receives the abnormal 
response message shown in figure 3-50. Figure 3-51 
shows the normal response to the def Ine-multiple- 
devlce-characteristics supervisory message. 

Valid combinations of FN/FV pairs are defined in 
table 3-2. Field numbers are listed in hexadecimal, 
with octal equivalents in parentheses. Field values 
are listed only in hexadecimal. 

The deflne-device-characterlstlcs and define- 
mul tipi e-device characteristics supervisory mes¬ 
sages sent downline by the application program are 
removed from the output stream by the TIP and acted 
on directly. The terminal operator is not advised 
of their occurrence in the output stream. 
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Application NAM Message 

The terminal operator enters the TC, PW, or PL commands to the Terminal Interface 
Program, 

- TCH/TCHAR/R 

The next block sent to the device or from the device is affected by any constraints 
imposed under the new device page width, page length, or terminal class. 

Application NAM TIP Message 

The application program changes a device characteristic other than page width, page 
length, or terminal class. 

--► CTRL/DEF/R 

The next block sent to the device or sent from the device is affected by any constraints 
imposed under the new device characteristic. 

Application NAM TIP Message 

The application program changes page width, page length, or terminal class. 

-► CTRL/DEF/R 

-m*- TCH/TCHAR/R 

The next block sent to the device or sent from the device is affected by any constraints 
imposed under the new page width, page length, or terminal class. 

Application NAM Message 

The application sends a define-raultiple-device-characteristics message to NAM in order 
to redefine several of the device characteristics with a single message. The message 
is properly formatted and the new characteristics take effect immediately. NAM replies 
with a define-device-characteristies normal response. 

-► CTRL/CHAR/R 

- CTRL/CHAR/N 

Application NAM Message 

The application sends a define-device-characteristics message to NAM, but one of the 
FN/FV pairs is bad. The changes do not take effect, and a define-device- 
characteristics abnormal response is sent to the application. 

-► CTRL/CHAR/R 

- CTRL/CHAR/A 


Figure 3-46. Device Characteristics Redefinition Supervisory Message Sequences 
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51 49 


tch 00 tchar res 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code 64.]^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol TCH. 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol TCHAR. 

Reserved by COC. Reserved fields contain zero. 

Application connection number assigned by the network software to this end of the logical con¬ 
nection for which the change occurred. This field always contains a value previously used by 
the application program in an FC/INIT/N message. You can access this field with the reserved 
symbol CONACN, as described in section 4. 

The terminal class currently associated with the real device by the TIP servicing it. The 
terminal class determines the parameters and ranges valid for redefinition of the device. The 
device is serviced by the TIP according to the attributes associated with the terminal class 
(see text). The tclass field can contain the values: 

0 Reserved for CDC use. 


Archetype terminal for the class 


is a Teletype Corporation Model 30 Series. 


Archetype terminal for the class is a CDC 713-10, 722-10, 751-1, 752, 756. 

Archetype terminal for the class is a COC 721. 

Archetype terminal for the class is an IBM 2741. 


Archetype terminal for the class 


is a Teletype Corporation Model 40-2. 


Archetype terminal for the class is a Hazeltine 2000, operating as a 
teletypewriter. 

Archetype terminal for the class is a VT100 (ANSI X3.64). 


Archetype terminal for the class 
teletypewriter. 


is a Tektronix 4000 Series, operating as a 


Archetype terminal for the class i 

Archetype terminal for the class i 

Archetype terminal for the class i 

Archetype terminal for the class i 
station. 

Archetype terminal for the class i 
Archetype terminal for the class i 
Archetype terminal for the class i 
Archetype terminal for the class i 


Archetype terminal for the class is a HASP (post-print) protocol multi leaving 
workstation. 

Archetype terminal for the class is a CDC 200 User Terminal. 


s a CDC 714-30. 


s a CDC 711-10. 


s a CDC 714-10/20. 


s a HASP (pre-print) protocol multi leaving work- 


s a CDC 734. 


s an IBM 2780. 


s an IBM 3780. 
s an IBM 3270. 


Figure 3-47. Device-Characteristics-Redefined (TCH/TCHAR/R) Supervisory 
Message Format (Sheet 1 of 2) 
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19 Reserved for CDC use. 

thru 

27 

28 Site-defined terminal class. 

thru 

31 

If the terminal class value received has not changed from that previously associated with the 
device, then the value in either the pw or pi fields Cor both) has usually changed. If the 
terminal class value received has changed from that previously associated with the device, 
then all attributes associated with the device have been changed to the default attributes for 
the new terminal class; the values in the pw and pi fields might have changed from those 
previously associated with the real device. You can access this field with the reserved 
symbol TCHTCL, as described in section 4. 

pw The most recently declared page width of the console device, specifying the number of 

characters in a physical line of output. This field can contain the values 0 or 20 < pw £ 
255. You can access this field with the reserved symbol TCHPW, as described in sectTon 4. 

pi The most recently declared page length of the console device, specifying the number of 

physical lines that constitute a page. This field can contain the values 0 or 8 £ pi £ 255. 
You can access this field with the reserved symbol TCHPL, as described in section 4. 


Figure 3-47. Device-Characteristics-Redefined (TCH/TCHAR/R) Supervisory 
Message Format (Sheet 2 of 2) 


59 51 49 43 35 27 19 11 3 0 


ta + 7 


59 55 47 43 41 35 31 23 19 11 7 0 


ta + 21 


ta Symbolic address of the application program's text area from which this synchronous 

supervisory message is sent. 

Ctrl Primary function code C1^^_ You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the reserved symbol CTRL. 

def Secondary function code 4, You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol DEFF. 

char^ Up to 112 7-bit ASCII characters of one.or more commands consisting of the network control 

character, characteristic mnemonic, and its desired setting. The characteristic and its 
value are separated by an equals sign. Multiple characteristics can be changed by separating 
the commands with the network control character. See the Terminal Interfaces reference 
manual for the possible commands that can be sent. 

res Reserved by CDC. Reserved fields contain zero. 


Figure 3-48. Define-Device-Characteristics (CTRL/DEF/R) Supervisory Message Format 


0 

Ctrl 

0 

B 

B 

def 

0 

charl 

0 

char2 

0 

char3 



__ 

0 

char109 

0 

charllO 

0 

charlll 

0 

char112 

res 


Ctrl 

0 

0 

def 

charl 

char2 

char3 

char4 

char5 

char6 

r 










_1 

charlH 

char112 

res 
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act =3 


ta Symbolic address of the application program text area from which this synchronous supervisory 

message is sent. 

Ctrl Primary function code C1^^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

char Secondary function code 8. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CHAR. 

fn^ The 8-bit field number of the parameter to be changed. 

fv^ The 8-bit field value for the parameter. 

Up to 56 field number and field value pairs can be specified in a single message. Valid 
field numbers and values are defined in table 3-2. 

res Reserved by COC. Reserved fields contain zero. 


Figure 3-49. Define-Hultiple-Device-Characteristics (CTRL/CHAR/R) Supervisory Message Format 


60499500 T 


3-57 





























ta 


ta 


ta 

Ctrl 

char 

fn 

re 


59 


51 49 


43 


35 


27 


Ctrl 


char 


fn 


59 55 


47 43 41 35 


31 


23 


19 


11 


Ctrl 


char 


fn 


act=2 


act=3 


Symbolic address of the application program text area receiving this synchronous supervisory 
message. 

Primary function code C1.j^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

Secondary function code 8. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CHAR. 

Field number causing the abnormal response. 

Reason code for error. This field can have the values: 

0 Reserved for CDC use. 

1 Out of range value for command or parameter 

2 Duplicate character definition 

3 Invalid command or parameter value for terminal class to which device belongs 

4 Invalid terminal class change 

5 Invalid command or parameter for terminal class to which device belongs 

6 thru Reserved for CDC use 
255 

Reserved by CDC. 


Figure 3-50. Define-Hultiple-Device-Characteristics Abnormal Response 
(CTRL/CHAR/A) Supervisory Message Format 


59 

51 49 43 


0 

ta Ctrl 

0 1 char 

res 

act=2 

59 55 

47 43 41 35 


0 

ta 0 

Ctrl 0 01 char 

res 

act=3 


ta Symbolic address of the application program's text area receiving this synchronous 

supervisory message. 

Ctrl Primary function code C1i^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

char Secondary function code 8. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CHAR. 

res Reserved by CDC. 

Figure 3-51. Hultiple-Device-Characteristics-Defined (CTRL/CHAR/N) Supervisory Message Format 
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TABLE 3-2. VALID CCP FIELD NUMBERS AND FIELD VALUES 



Field 

Usable for 

Field 


Command (Mnemonic) 

Number 

Terminal 

Value 

Field Value Content Meaning 


(Octal) 

Classes 

Range 


Abort block (AB) 29 (51) 


Blocking factor (BF) 19 (31) 


Break as user break 1 33 (63) 

(BR) 


Backspace character 27 (47) 

(BS) 


User break 1 character 2A (52) 
(Bl) 


User-break-2 character 2B (53) 

(B2) 

Enable transparent 95 (225) 

user break commands 

Carriage return idle 2C (54) 

count (Cl) 


2E (56) 


Cancel character (CN) I 26 (46) 


Cursor positioning 47 (107) 

(CP) 


Network control 28 (50) 

character (CT) 

Single message 38 ( 70) 

transparent input 
delimiters (DL) 

Message and mode 39 (71) 

delimiter 


Message and mode 3A (72) 

delimiter 


Message and mode 3B (73) 

delimiter 


1 thru 8, (D 
28 thru 31 
(9 thru 18) 

1 thru 8, 10 thru 
13. 15, 18 ( 1 ) 

(9, 14, 16, 

17) 

1 thru 3, 

5 thru 8, 

28 thru 31 
(4, 9 thru 18) 

1 thru 8, 

28 thru 31 
(9 thru 18) 

1 thru 15, 18, 

28 thru 31 
(16. 17) 

1 thru 15, 18, 

28 thru 31 
(16, 17) 

1 thru 8, 

10 thru 13. 15 

1 thru 8, 

28 thru 31 
(9 thru 18) 

1 thru 8, 

28 thru 31 
(9 thru 18) 

1 thru 15, 18, 

28 thru 31 
(16, 17) 

1 thru 3, 

5 thru 8, 

28 thru 31 
(4, 9 thru 18) 

1 thru 18, 

28 thru 31 

1 thru 8, 

28 thru 31 
(9 thru 18) 

1 thru 3, 

5 thru 8, 

28 thru 31 
(9 thru 18) 

1 thru 3, 

5 thru 8, 

28 thru 31 
(9 thru 18) 

1 thru 8, 10 
thru 13, 15, 18, 
28 thru 31 
(9, 14, 16, 17) 


0 thru 7E (D 

Numerical value for character 

0 thru 20 

Multiple of 100 characters 


that constitute an upline 


block 

0 or 1 

Yes (1), no ( 0 ) 

0 thru 7E (3) 

Numerical value for character 

0 thru 7E @ 

Numerical value for character 

0 thru 7E 

Numerical value for character 

0 or 1 

Yes (1), no (0) 

0 thru 7F 

Number to Insert 

1 

TIP should calculate number 

0 thru 7E (3) 

Numerical value for character 

0 or 1 

Yes (1), no (0) 

0 thru 7E (3) 

Numerical value for character 

0 or 1 

Character specified (1), not 


specified (0) 

0 thru OF 

Character count (upper byte) 

0 thru FF 

Character count (lower byte) 

0 thru FF (5) 

Numerical value for character 
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TABLE 3-2. VALID CCP FIELD NUMBERS AND FIELD VALUES (Contd) 


Command (Mnemonic) 

Field 

Number 

(Octal) 

Usable for 
Terminal 

Classes 

Field 

Value 

Range 

Field Value Content Meaning 

Message and mode 
delimiter 

3C (74) 

1 thru 3, 5 thru 

8, 28 thru 31 
(9 thru 18) 

0 or 1 

Timeout (1), no timeout (0) 

Mode type 

46 (106) 

1 thru 8, 10 
thru 13, 15, 18, 

28 thru 31 

0 

Single message (0) 

End-of-block character 
(EB) 

40 (100) 

1 thru 3, 5 thru 

8, 10 thru 13, 

15, 18, 28 thru 

31 

0 thru FF (D 

Numerical value for character 

Use default 
terminator 

41 (101) 

1 thru 3, 5 thru 

8, 10 thru 13, 

15, 18, 28 thru 

31 

1 or 2 @ 

End-of-line (1), end-of-block 
(2) 

End-of~block cursor 
positioning response 

42 (102) 

1 thru 3, 5 thru 

8, 10 thru 13, 

15, 18, 28 thru 

31 (9, 14, 16, 

17, 18) 

0 thru 3 (D 

No (0), CR (1), LF (2), CR 
and LF (3) 

End-of-line character 
(EL) 

3D (75) 

1 thru 3, 5 thru 

8, 10 thru 13, 

15, 18, 28 thru 31 

0 thru 7F @ 

Numerical value for character 

Use default 
terminator 

3E (76) 

1 thru 3, 5 thru 

8, 10 thru 13, 

15, 18, 28 thru 

31 

1 or 2 

End-of-line (1), end-of-block 
(2) 

End-of-llne cursor 
positioning response 

3F (77) 

1 thru 3, 5 thru 

8, 10 thru 13 

15, 28 thru 31 
(9. 14, 16, 17, 

18) 

0 thru 3 (5) 

No (0), CR (1), LF (2), CR 
and LF (3) 

Echoplex mode (EP) 

31 (61) 

1 thru 3, 

5 thru 8, 

28 thru 31 
(4, 9 thru 18) 

0 or 1 

Yes (1), no (0) 

Full ASCII input (FA) 

37 (67) 

1 thru 8, 10 
thru 13, 15, 

16, 17, 18, 

28 thru 31 

0 or 1 

Yes (1), no (0) 

Input control (IC) 

43 (103) 

1 thru 3, 

5 thru 8, 

28 thru 31 
(4, 9 thru 18) 

0 or 1 

Yes (1), no (0) 

Input device (IN) 

34 (64) 

1 thru 8, 10 
thru 13, 15, 

28 thru 31 

0 or 1 

Transparent input (1), not 
transparent (0) 


35 (65) 

1 thru 8, 

28 thru 31 

0 thru 2 (5) 

Keyboard (0), paper tape (1), 
block mode (2) 
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TABLE 3-2. VALID CCP FIELD NUMBERS AND FIELD VALUES (Contd) 


Command (Mnemonic) 

Field 

Numbe r 
(Octal) 

Usable for 

Terminal 

Classes 

Field 

Value 

Range 

Field Value Content Meaning 

Line feed Idle count 
(LI) 

2D (55) 

2F (57) 

1 thru 8, 

28 thru 31 
(9 thru 18) 

1 thru 8, 

28 thru 31 
(9 thru 18) 

0 thru 7F 

1 

Number to insert 

TIP should calculate number 

Lockout unsolicited 
messages (LK) 

20 (40) 

1 thru 15, 18, 

28 thru 31 
(16) 

0 or 1 

Yes (1), no (0) 

Output control (OC) 

44 (104) 

1 thru 3, 

5 thru 8, 

28 thru 31 
(4, 9 thru 18) 

0 or 1 

Yes (1), no (0) 

Output device (OP) 

36 (66) 

1 thru 8, 

28 thru 31 
(9 thru 18) 

0 thru 2 @ 

Printer (0), display (1), 
paper tape (2) 

Parity processing (PA) 

32 (62) 

1 thru 3, 5 thru 

8, 28 thru 31 

0 thru 4 

Zero (0), odd (1), even (2), 
none (3), ignore (4) 

Page waiting (PG) 

25 (45) 

1 thru 8, 10 
thru 13, 15, 18, 

28 thru 31 
(9, 14, 16, 17) 

0 or 1 

Yes (1), no (0) 

Page length (PL) 

24 (44) 

1 thru 18, 

28 thru 31 

0, 8 thru FF @ 

Number of physical lines 

Page width (PW) 

23 (43) 

1 thru 18, 

28 thru 31 

0, 20 thru FF 

Number of characters 

Site-defined use 

5A thru 63 
(132 thru 
143) 

i thru 18 , 

28 thru 31 

0 thru FF @ 

Site-defined 

Special editing mode 
(SE) 

30 (60) 

1 thru 8, 

28 thru 31 
(9 thru 18) 

0 or 1 

Yes (1), no (0) 

Terminal class (TC) 

22 (42) 

1 thru 10, ® 

28 thru 31 

01 thru OF (?) 

Number of new class 

Multiple-message 
transparent 
delimiters (XL) 

38 ( 70) 

1 thru 8, 

28 thru 31 
(9 thru 18) 

0 or 1 

Character specified (1), not 
specified (0) 

Message delimiter 

39 (71) 

1 thru 3, 5 thru 

8, 28 thru 31 
(9 thru 18) 

0 thru F 

Character count (upper byte) 

Message delimiter ; 

3A (72) 

1 thru 3, 5 thru 

8, 28 thru 31 
(9 thru 18) 

0 thru FF 

Character count (lower byte) • 

Message delimiter 

3B (73) 

1 thru 8, 10 
thru 13, 15, 18, 

28 thru 31 
(9, 14, 16) 

0 thru FF (D 

Numerical value for character 
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TABLE 3-2. VALID CCP FIELD NUMBERS AND FIELD VALUES (Contd) 
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EFFECTS OF CHANGING TERMINAL 
CLASS ON CDCNET 

Changing terminal class affects many of the CDCNET 
attributes. There are changes to the attribute 
settings that are associated with all terminal 
class changes. These changes are shown in table 
3-3. There are also changes to the attribute 
settings that are associated only with specified 
terminal classes. These changes are shown in table 
3-4. 


REQUESTING CCP DEVICE 
CHARACTERISTICS 

The request-device-characteristics supervisory 
message (figure 3-52) is issued by an - application 
program on console or site-defined device connec¬ 
tions to learn the current value of the device 
characteristics. The application program specifies 
a string of pairs of 8—bit numbers starting after 
the secondary function code field and extending for 
as many 8-blt bytes as necessary. The application 
stores a field number (FN) in the first half (8 
bits) of the 8-blt pair and reserves the second 
half (8 bits) for a field value (FV). Each FN 
represents a particular characteristic. The network 
returns the value of the characteristic in the 


TABLE 3-3. CDCNET ATTRIBUTE CHANGES 
ASSOCIATED WITH ALL TERMINAL CLASS CHANGES 


CDCNET 

Attribute 

Se ttlng 
Change 

CDCNET 

Attribute 

Setting 

Change 

BKA 

0 

P 

EVEN 

CFC 

TRUE 

PCF 

FALSE 

CLC 

CAN 

SA 

SEND 

E 

FALSE 

SBC 

FALSE 

ELC 

CR 

SND 

FALSE 

ELP 

LFS 

TCM 

TERMINATE 

EPC 

LF 

TFC 

CR 

EPP 

CRS 

TLM 

TERMINATE 

HP 

NO 

TML 

2043 

NCC 


TIM 

NONE 


corresponding FV byte. Any value placed in the FV 
byte by the application is ignored and overwritten. 
The application program needs to specify only the 
FNs for the characteristics it is interested in. 
If the string contains an incorrect FN, no device 
characteristics are returned and the application 
receives the abnormal response message shown in 
figure 3-53. For a list of legal FNs and the cor¬ 
responding range of possible FVs, see table 3-2. 


TABLE 3-4. CDCNET ATTRIBUTE SETTING CHANGES ASSOCIATED WITH SPECIFIED TERMINAL CLASSES 


CDCNET 

Terminal Classes 

Attribute 

I 


3 

5 

6 

7 

8 

BC 

BS 

BS 

BS 

none 

BS 

BS 

BS 

CRDt 

2 

0 

0 

1 

0 

0 

0 

CRS 

CR 

CR 

CR 

ESC G 

CR 

CR 

CR 

FFD 

na 

na 

na 

na 

na 

na 

999ms 

FFS 

6 

EM/ 

FF 

ESC R 

FS 

ESC[H 

ESC 



LFs 

CAN 




ESC [J 

FF 


FL 

YES 

NO 

NO 

NO 

NO 

NO 

NO 

LFDt 

1 

0 

0 

3 

3 

0 

0 

LFS 

LF 

LF 

LF 

ESC B 

0 

LF 

LF 

PL 

0 

24 

30 

24 

27 

24 

35 

PW 

72 

80 

80 

80 

74 

80 

74 


TMillisecond value is dependent on llnespeed. 
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ta 


59 


51 49 


43 


35 


27 


19 


11 


Ctrl 


rtc 


fni 


fvi 


fn2 


fV2 


ta Symbolic address of the application program's text area from which this synchronous super¬ 

visory message is sent. 

Ctrl Primary function code Cl-i^. You can access this field with the reserved symbol PFC, as • , 

described in section 4. Its value is defined as the value of the reserved symbol CTRL., . 

rtc Secondary function code 9. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol RTC. 

fn^ The hexadecimal field number of the desired parameter. Valid values are defined in table 3-2. 

fvj Space for the hexadecimal field value of the desired parameter; can be 0. 


Figure 3-52. Request-Device-Characteristics CCTRL/RTC/R) Supervisory Message Format 


59 51 49 43 35 27 0 



ta Symbolic address of the application program's text area receiving this synchronous 

supervisory message. 

Ctrl Primary function code Cl-ig. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

rtc Secondary function code 9. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol RTC. 

fn First field number in the string found to be erroneous by the network software. In case of 

several bad field numbers, only the first bad one will be diagnosed. 

rc Reason code for error. This field can have the value: 

0 Reserved for CDC use 

thru 

4 

5 Invalid field number value 

6 Reserved for CDC use 
thru 


res Reserved by CDC. 


figure 3-53. Request-Device-Characteristics Abnormal Response (CTRL/RTC/A) Supervisory Message Format 
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The response to a request-device-characteristics 
supervisory message is a device-characteristics 
definition message (figure 3-54). This message can 
be received only on console or site-defined device 
connections. The NPU generates a string of pairs 
of 8-bit numbers starting after the secondary func¬ 
tion code field and extending for as many 8—bit 
bytes as necessary. The first 8-bits of the 16-bit 
pair is one of the field numbers specified in the 
request-device-characteristics supervisory mes¬ 
sage. The second 8-blts of the 16-blt pair is the 
current value of the particular characteristic the 
FN represents. For a list of valid FNs and the 
associated valid range of FVs, see table 3-2. 


CHANGING CDCNET TERMINAL 
CHARACTERISTICS 

The CONNET flag is defined in the CON/REQ/R super¬ 
visory message and indicates whether the termlnal- 
to-applicatlon connection is through CCP or 
CDCNET. This flag is set by NAM when NAM creates 
and returns the connection-request supervisory 
message to the application program requesting the 
connection to the device. 

In a CDCNET network, attributes are operating 
characteristics of either the terminal or the con¬ 
nection. Changing a connection attribute affects 


only data on that connection, but changing a ter¬ 
minal attribute affects all connections with the 
terminal. 


The defIne-CDCNET-terminal-characteristics super¬ 
visory message is described in figure 3-55. This 
message specifies a string of 8-bit bytes beginning 
after the secondary function code field and extend¬ 
ing for as many 8-bit bytes as necessary. The 
application program stores an attribute number (AN) 
in the rightmost 7 bits of the first byte. The 

leftmost bit of the 8-bit byte is used by the 

application program to indicate the contents of the 
byte following the AN byte. If the leftmost bit of 
the AN byte is 1, the 8-blt byte following the AN 
byte contains the length of the attribute value 
(AV) field. The length bit is followed by the 

attribute value field. If the leftmost bit of the 
AN byte is 0, the corresponding attribute value is 
stored in the byte following the AN byte (there is 
no length byte). Following the AV field are more 
AN/AV fields for as many bytes as necessary to 

contain all the characteristics that are being 

changed. 


Each AN represents a particular terminal character¬ 
istic (or attribute) that corresponds to a terminal 
definition parameter. The corresponding AV repre¬ 
sents the value the application program wishes to 
assign to the characteristic (or attribute). 


59 

51 

49 

43 

35 

27 

19 

11 0 

Ctrl 

0 

0 

ted 

fni 

fvi 

fng 

fV2 

... 


ta 

Ctrl 


ted 




fvs 


Symbolic address of the application program's text area receiving this synchronous supervisory 
message. 

Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

Secondary function code You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol TCD. 

The hexadecimal field number of the characteristic parameter. Valid, values are defined in 
table 3-2. 

The hexadecimal field value of the characteristic parameter. Valid values are defined in table 
3-2. 


Figure 3-54. Device-Characteristics-Definition (CTRL/TCD/R) Supervisory Message Format 
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ta 


ta+n 


ta 


Ctrl 


ctd 


59 

55 

47 

43 

41 

35 

31 

23 

19 

11 

7 0 

0 

Ctrl 

0 

0 

0 

ctd 

0 

an-i 

0 

av-) 

0 

an2 

= 












0 

a^m 

0 

avm 

0 

ai^m+l 

0 

a''m+1 

... 


act=3 


Symbolic address of the application program text area from which this synchronous supervisory 
message is sent. 

Primary function code C1^^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

Secondary function code 02. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CTD. 

The 8-bit attribute number of the parameter to be changed. When the uppermost bit of the AN 
field is set, it indicates that the next 8-bit field contains the number of AVs following 
this AV count field; otherwise, the next field will be a single 8-bit field which is the 
value of the AV. 

The 8-bit attribute value of the parameter to be changed, or, if the immediately preceding 
field is an AN with the uppermost bit set, the number of AVs that follow. 

The formats are: 

Single Octet Value 


0 

Attribute Number 

Attribute Value 



Octet 1 


Multiple Octet Value 


Octet 2 



Valid attribute numbers and values are defined in table 3-5. 


Figure 3-55. Define-CDCNET-Terminal-Characteristics <CTRL/CTD/R) Supervisory Message Format 
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supervisory message shown In figure 3-56. Figure 
3-57 shows the normal response to the define- 
CDCNET-termlnal-characteristlcs supervisory message. 


The application program needs to specify only the 
AN/AV pairs for the characteristics It wants to 
change. If one of the AN/AV pairs contains an 
incorrect value, no characteristics change and the 
application program receives the abnormal response Valid combinations of AN/AV pairs are defined in 

table 3-5. 



59 

51 

49 


43 



35 


27 


19 


0 


ta 

Ctrl 

1 

0 

ctd 

PC 

an 

av 

pes 

act=2 


59 

55 



47 

43 


41 

35 

31 


23 

19 

11 

7 0 


ta 

0 

Ctrl 

0 

1 

0 

ctd 

0 

PC 

0 

an 

0 

av 

act=3 


ta Symbolic address of the application program text area receiving this synchronous supervisory 

message. 

Primary function code C1-|^, You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

dtd Secondary function code 02. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CTD. 

rc Reason code for the error. This field can have the values: 

0 Attempt to change an unknown attribute; no attributes were changed 

1 Attempt to change a known attribute to an invalid value; no attributes were changed 

2 Attribute length out of range; no attributes were changed 

3 Character definition values in conflict; no attributes were changed 


an 

Attribute 

number 

causing 

the 

abnormal 

response. 

av 

Attribute 

value 

causing 

the 

abnorma1 

response. 

P8S 

Reserved 

by CDC. 






Figure 3-56. Oefine-CDCNET-Terminal-Characteristics Abnormal Response (CTRL/CTD/A> 

Supervisory Message Format 



act=2 


act=3 


ta Symbolic address of the application program's text area receiving this synchronous 

supervisory message. 

ctfl Primary function code Cl.]^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

ctd Secondary function code 02. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CTD. 

res Reserved by CDC. 


Figure 3-57. Define-CDCNET-Terminal-Characteristics (CTRL/CTD/N) Supervisory Message Format 
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TABLE 3-5. VALID CDCNET ATTRIBUTE NUIIBERS AND ATTRIBUTE VALUES BOR ASYNCHRONOUS TERMINALS 


Command (Mnemonic) 

Attribute 
Number(Octal) 

Attribute 

Value Range 

Attribute Value 

Content Meaning 

Attention character (AC) 

46 (106) 

1 8-bit byte 

Character 

Attention character 
action (ACA) 

OA (12) 

0 thru 9 

Action codes 

Backspace character (BC) 

44 (104) 

1 8-bit byte 

Character 

Break key action (BKA) 

OB (13) 

0 thru 9 

Action codes for break key 

Begin line character (BLC) 

43 (103) 

1 8-bit byte 

Character 

Character flow control (CFG) 

56 (126) 

- 

0 or 1 

No (0), yes (1) 

Cancel line character (CLC) 

41 (101) 

1 8-bit byte 

Character 

Carriage return delay (CRD) 

51 (121) 

0 thru 1000 

Delay in milliseconds 

Carriage return sequence (CRS) 

4D (115)t 

0 thru 2 8-biC bytes 

Any 0 thru 2 characters 

Code set (CS) 

58 (130) 

0, 1, or 2 

ASCII (0), BPAPL (1), TPAPL (2) 

Echoplex (E) 

5A (132) 

0 or 1 

Off (0), on (1) 

End line character (ELC) 

42 (102) 

1 8“bit byte 

Character 

End line positioning (ELP) 

54 (124) 

0 thru 3 

None (0), CRS (1), LFS (2), 

CRSLFS (3) 

End output sequence (EOS) 

4C (114)t 

0 thru 4 8-blt bytes 

Any 0 thru 4 characters 

End page action (EPA) 

50 (120) 

0 or 1 

No (0), yes (l> 

End partial character (EPC) 

45 (105) 

1 8-bit byte 

Character 

End partial position (EPP) 

55 (125) 

0 thru 3 

None (0), CRS (1), LFS (2), 

CRSLFS (3) 

Form feed delay (FFD) 

53 (123) 

0 thru 3000 

Delay in milliseconds 

Form feed sequence (FFS) 

4F (117)t . 

0 thru 7 S-biC bytes 

Any 0 thru 7 characters 

Fold line (FL) 

4B (113) 

0 or 1 

No (0), yes (1) 

Hold page (HP) 

49 (111) 

0 or 1 

No (0), yes ( 1) 

Hold page over (HPO) 

4A (112) 

0 or 1 

No (0), yes (1) 

Input block size (IBS) 

OC (14) 

80 thru 2000 

Block size for input 

Input editing mode (lEM) 

2 (2) 

0 or 1 

Normal (0), transparent (1) 

Input output mode (lOM) 

i (1) 

0, 1, or 2 

Unsolicited (0), solicited (1), 
full duplex (2) 

Line feed delay (LFD) 

52 (122) 

0 thru 1000 

Delay in milliseconds 

Line feed sequence (LFS) 

4E (116)t 

0 thru 2 8-bit bytes 

Any 0 thru 2 characters 

Network command character 
(NCC) 

40 (100) 

1 8-bit byte 

Character 

Parity (P) 

59 (131) 

0 thru 4 

Zero (U), mark (1), even (2), 
odd (3), none (4) 
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TABLE 3-5. VALID CDCNET ATTRIBUTE NUMBERS AND ATTRIBUTE VALUES EOR ASYNCHRONOUS TERMINALS (Contd) 


Command (Mnemonic) 

Attribute 

Number(Octal) 

Attribute 

Value Range 

Attribute Value 

Content Meaning 

Partial character forwarding 

9 (11) 

0 or 1 

No (0), yes (1) 

(PCF) 



Page length (PL) 

47 (107) 

0, 2 thru 255 

Number of physical lines 

Page width (PW) 

48 (110) 

0, 10 thru 255 

Number of characters 

Status action (SA) 

5B (133) 

0, 1, or 2 

Send (0), bold (1), discard (2) 

Store backspace character 

OE (16) 

0 or 1 

No (0), yes (1) 

(SBC) 



Store nuls dels (SND) 

OD (15) 

0 or 1 

No (0), yes (1) 

Transparent character mode 

3 (3)t 

1 thru 4 8-bit bytes 

None (0), terminate (1), forward 

(TCM) 



(2), forward and terminate (3) 

Transparent forward character 

4 (4)t 

1 thru 4 8-blt bytes 

1 thru 4 characters 

(TFC) 




Transparent length mode (TLM) 

7 (7) 

0 thru 3 

None (0), terminate (1), forward 




(2), forward exact (3) 

Terminal model (TM) 

57 (127)t 

1 thru 25 8-blt 

Terminal model identifier 



bytes 


Transparent message length 

8 (10) 

1 thru 7FFF 

Number of transparent characters 

(TML) 



to forward 

Transparent terminate 

5 (5)t 

1 thru 4 8-bit bytes 

1 thru 4 characters 

character (TTC) 




Transparent timeout mode (TTM) 

6 (6)t 

0 thru 2 

None (0), terminate (1), 




forward (2) 

tThe AN of these attributes has its uppermost bit set to indicate that the 
field followed by as many AVs as indicated in the count field. 

next 8-btt field is an AV count 


CONVERTING ATTRIBUTES 

Table 3-6 shows the mappings between FN/FV pairs 
and the corresponding CDCNET attributes. 

When an application program defines multiple 
terminal characteristics for transparency, FNs 56, 


57, 58, 59, 60, 69, 70, and 146 should be sent 

together to insure proper results. The conversion 
of these FNs to CDCNET attributes is a complex 
process. There are subtle differences between the 
CCP and CDCNET transparent input features. If your 
applications are having problems with transparent 
input, review table 3-6. carefully. 
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TABLE 3-6. CCP FIELD NUMBER TO CDCNET ATTRIBUTE NUMBER MAPPING 


CCP Field Number 

Field Name 

Field Value 

CDCNET Changes 

CDCNET 

Attribute Number 

-1 

Dec* 

Hex. 

Oct. 

Dec. 

Hex. 

Oct. 

25 

19 

31 

BF 

0 

1 

PCF=TRUE 

PCF=FAlSE, IBS=10U 
PCF=FALSE, IBS=200 

9 

9 

11 

30 

IE 

36 

XBZl 

all 

none 

none 

■ 31 

IF 

37 

XBZ2 

all 

none 

none 

32 

20 

40 

LK 

0 

1 

SA=SEND 

SA=D1SCARD 

91 

58 

133 

33 

21 

41 

HD 

all 

none 

none 

34 

22 

42 

TC 

all 

® 

87 

5/ 

127 

35 

23 

43 

PW 

n 

PW=n 

72 

48 

110 

36 

24 

44 

PL 

n 

PL=ii 

71 

B 

107 

37 

25 

45 

PC 

0 

1 

HP=FALSE 

HP=TRUE 

73 

49 

111 

38 

26 

46 

CN 

char 

CLC=char 

65 

41 

101 

39 

27 

47 

BS 

char 

BC=char 

68 


lu4 

40 

28 

50 

CT 

char 

NCC=char 

64 

40 

100 

41 

29 

51 

AB 

all 

■»one 

none 

42 

2A 

52 

B1 

all 

none 

none 

43 

2B 

53 

B2 

all 

none 

none 

44 

2C 

54 

Cl 

n 

CRD=n*linespeed factor 

• 81 

51 

121 

45 

2D 

55 

LI 

n 

LFD=n*linespeed factor 

82 

52 

111 

46 

2E 

56 

CA 

all 

none 


none 


47 

2F 

57 

LA 

all 

none 

none 

48 

30 

60 

SE 

0 

1 

SBC=FALSE, EPC=LF 
SBC=TRUE, EPC=NUL, 

CLC=NUL 

14 

OE 

16 

49 

31 

61 

EP 

0 

1 

E=FALSE 

E=TRUE 

90 

5A 

132 

50 

32 

62 

PA 

0 

1 

2 

3 

4 

P=ZERO 

P=ODD 

P=EVEN 

P=NONE 

P=NONE 

89 

59 

131 

51 

33 

63 

BR 

0 

1 

BKA=0 

BKA=1 

a 

OB 

13 

52 

34 

64 

XPT 

0 

1 

1EM=N0RMAL 

1EM=TRANSPARENT 

1 

■ 

1 

53 

35 

65 

IN 

all 

none 

none 
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TABLE 3-6. CCP FIELD NUMBER TO CDCNET ATTRIBUTE NUMBER MAPPING (Contd) 


I 


CCP Field Number 


Field Value 

CDCNET Changes 

CDCNET 

Attribute Number 

Dec. 

Hex. 

Oct. 

rield Name 

Dec. 

Hex* 

Oct. 

54 

36 

66 

OP 

0 . 

1 

2 

FL=FALSE 

FL=TRUE 

none 

75 

4B 

113 

55 

37 

67 

FA 

0 

1 

EPC=LF, SBC=FALSE, 
SND=FALSE 

EPC=NUL, SBC=TRUE, 
SND=TRDE 

69 

45 

105 

56 

38 

70 

DL or XL 

0 

1 when FN 70=0 

1 when FN 70=1 

TCM=N0NE 

TCM=TERMINATE 

TCM=F0RWARD TERMINATE 

3 

3 

3 

57 

39 

71 

DL or XL 

Not specified & FN 58 
is not specified 
Specified & FN 58 is 
specified 

TLM=NONE 

TML=value of FN 58 + 

256*(value of FN 57) 

■ 

1 

■ 

58 

3A 

72 

DL or XL 

Not specified & FN 57 
is not specified 
Specified & FN 57 is 
specified 

--- 

TLM=NONE 

TML=value of FN 58 + 
256*(value of FN 57) 

■ 

1 

7 

59 

3B 

73 

DL or XL 

Specified 

Specified as CR & 
terminal parlty= 
IGNORE 

TFC=value of FN 59 
TFC=(04 i6,84i6) 

■ 

1 

■ 

60 

3C 

74 

DL or XL 

0 

1 & FN 70 or FN 146=0 

1 & FN 70 & FN 146=1 

TTM=NONE 

TTM=TERMINATE 

TTM=FORWARD 

■ 

■ 

6 

61 

3D 

75 

EL 

char 

ELC=char 

66 

42 

102 

62 

3E 

76 

ELO 

all 

none 


none 


63 

3F 

77 

CPEL 

0 

1 

2 

3 

ELP=N0NE 

ELP=CRS 

ELP=LFS 

ELP=CRSLFS 

84 

54 

124 

64 

40 

100 

EB 

all 

none 

none 

65 

41 

101 

EBO 

all 

none 

none 

66 

42 

102 

CPEB 

all 

none 

none 

67 

43 

103 

IC 

0 

1 

CFC=FALSE 

CFC=TRUE 

86 

56 

126 

68 

44 

104 

OC 

0 

1 

CFC=FALSE 

CFC=TRUE 

86 

56 

126 

69 

45 

105 

■XL 

Specified 

Specified as CR & 
terminal parlty= 

IGNORE 

TTC=value of FN 69 
TTC=(04ig,84i6) 

5 

5 

5 

70 

46 

106 

DL or XL 

0 

1 & FN 59 is 

specified but not 

FN 69 

1 & TML=1 

1 & TML=1 

TLM=TERMINATE 

TTC=TFC 

TLM=F0RWARD 

TLM=FORWARD_EXACT 

1 

1 

7 
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TABLE 3-6. COP FIELD NUMBER TO CDCNET ATTRIBUTE NUMBER MAPPING (Contd) 


CCP Field Number 

Field Name 

Field Value 

CDCNET Changes 

CDCNET 

Attribute Number 

Dec- 

Hex, 

Oct, 

Dec. 

Hex. 

Oct. 

71 

47 

107 

CP 

0 

1 

ELP=NONE, EPP=N0NE 
ELP=LFS, EPP=CRS 

84 

54 

124 

87 

57 

127 

FDLX 

0 

1 

ICM=SOLICITED 

I0M=FULLDUPLEX 

■ 

1 

1 

102 

66 

146 

PP 

char 

E0S=char 

76 

4C 

114 

112 

70 

160 

NTA 

0 

1 

lOMmNSOLICITED 

I(M=S0LICITED 

■ 

■ 

1 

147 

93 

223 

CRI 

n 

CRD=n*4 

81 

51 . 

121 

148 

94 

224 

LFI 

n 

LFD=n*4 

82 

52 

122 

(T) See section on Effects of Changing Terminal Class on CDCNET. 


REQUESTING CDCNET TERMINAL 
CHARACTERISTICS 

The request-CDCNET-termlnal-characterlstlcs super¬ 
visory message (figure 3-57.1) is Issued by an 
application program to learn the current values of 
either connection or terminal attributes. The 
application program specifies a string of 8-blt 
numbers starting after the secondary function code 
field and extending for as many 8—bit bytes as 
necessary. The application program stores an 
attribute number (AN) in each byte. Each AN repre¬ 
sents a particular characteristic. The application 
program needs to specify only the ANs for the 
characteristics it is Interested in. If the string 
contains an Incorrect AN, no characteristics are 
returned and the application program receives the 
abnormal response message shown in figure 3-57.2. 
Valid AN values are listed in table 3-5. 


The response to a request-CDCNET-termlnal- 
characteristics supervisory message is the CDCNET- 
termlnal-characteristics-definitlons supervisory 


message shown in figure 3-57.3. This message 
contains a string of 8-bit bytes starting after the 
secondary function code field and extending for as 
many 8-blt bytes as necessary. The first 8-bit 
byte contains one of the attribute numbers speci¬ 
fied in the request-CDCNET-termlnal-characteristlcs 
supervisory message. The attribute number is in 
the rightmost 7 bits of the 8-bit byte. The left¬ 
most bit of the 8-bit AN byte is used to indicate 
whether the attribute value which the AN represents 
is contained in the following byte. If the leftmost 
bit of the AN byte is 1, the 8-bit byte following 
the AN byte is the length of the attribute value 
(AV) field. The length byte is followed by the 
attribute value field. If the leftmost bit of the 
AN byte is 0, the corresponding attribute value is 
in the next byte. More AN/AV fields follow the AV 
field for as many bytes as necessary to return all 
the attribute values requested. The AN/AV pairs in 
the CDCNET-terminal-characteristics-definitions 
supervisory message are not in the order speci¬ 
fied in the request-CDCNET-terminal-characterlstlcs 
supervisory message. The response message may 
contain duplicate AN/AV pairs. 
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ta 


Ctrl 


an 


ta 


ta 


59 

51 


49 

43 

35 


27 

19 

11 


3 0 

Ctrl 

0 

0 

rcc 

an 

an 

an 

an 

an 

an 

s 





an 

an 

an 

an 

an 

an 

an 


59 55 


47 43 41 35 31 


23 19 


117 0 


0 

Ctrl 

0 

a 

a 

rcc 

0 

an 

0 

an 

0 

an 








an 

_ 

an 


an 

■ 

an 

■ 

an 


act=2 


act=3 


Symbolic address of the application program text area receiving this synchronous super¬ 
visory message. 

Primary function code Cl^z You can access this field with the reserved symbol PFC, as 
described in section 4. . its value is defined as the value of the reserved symbol CTRL. 

Secondary function code You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol RCC. 

The 7-bit attribute number of the desired parameter. Valid values are defined in table 3-5. 


Figure 3-57.1 Request-COCNET-Terrainal-Characteristics <CTRL/RCC/R) Supervisory Message Format 



59 

51 49 

43 

35 




0 


ta 

Ctrl 

1 0 rcc 

an 




res 


act=2 


59 55 

47 

43 41 

35 

31 


23 

0 


ta 

0 

Ctrl 0 

0 0 rcc 

0 


an 


res 

aet=3 


ta Symbolic address of the application program text area receiving this synchronous super¬ 

visory message. 

Ctrl Primary function code C1^^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

rcc Secondary function code OB^^. You can access this field with the reserved symbol SFC,- as 

described in section 4. Its value is defined as the value of the reserved symbol RCC. 

an Attribute number that was invalid. 

res Reserved for CDC. 

Figure 3-57.2 Request-CDCNET-Terminal-Characteristics Abnormal 
Response (CTRL/RCC/A) Supervisory Message Format 
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ta 


Ctrl 


ccd 


59 55 


47 


43 


41 


35 31 


23 


19 


11 


ta 


ta+n 


0 

Ctrl 

0 

0 

0 

ccd 

0 

an^ 

0 

av^ 

0 

an2 

C 2 

r_: 

0 


0 

3''m 

0 

®"m+1 

B 

aVriH-l 

... 


act=3 


Symbolic address of the application program text area from which this synchronous supervisory 
message is sent. 

Primary function code Cl-]^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol CTRL. 

Secondary function code OC-ig. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol CCD. 

The 8-bit attribute number of the parameter to be changed. When the uppermost bit of the AN 
field is set, it indicates that the next 8-bit field contains the number of AVs following 
this AV count field; otherwise, the next field will be a single 8-bit field which is the 
value of the AV. 

The 8-bit attribute value of the parameter to be changed, or, if the immediately preceding 
field is an AN with the uppermost bit ^et, the number of AVs that follow. 

The formats are: 

Single Octet Value 


Attribute Number 


Octet 1 


Attribute Value 


Octet 2 


Multiple Octet Value 


1 Attribute Number n = number of AVs 


Octet 1 


Octet 2 


Attribute Value Octet 1 


Octet 3 


Octet n + 2 


Valid attribute numbers and values are defined in table 3-5. 


Figure 3-57.3 CDCNET-Terminal-Characteristics-Definitions CCTRL/CCD/R) Supervisory Message Format 
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HOST OPERATOR COMMANDS 

The host operator can send commands to an applica¬ 
tion program through the system console K-display. 
There are seven commands an application program 
might receive. Each command is delivered to the 
application program as a separate asynchronous 
supervisory message, as shown in figure 3-58. 

The host operator request-to-actlvate-debug-code 
supervisory message (figure 3-59) is sent from NAM 
to the application program when the operator enters 
the K-display command: 

K. DB=appname 

The application should begin using any in-line 
debug code you have Included. Activating in-line 
debug code can change the application program's 
abort conditions or error case handling or both. 


There is no response to the request-to-activate- 
debug-code message. 

The host operator request-to-turn-off-debug-code 
supervisory message shown in figure 3-60 is sent 
from NAM to Che application program when the 
operator enters the K-display command: 

K. DE=appname 

The application should turn off any in-line debug 
code you have included. There is no response to 
the request-to-turn-off-debug-code message. 

The host operator request-to-dump-field-length 
supervisory message (figure 3-61) is sent from NAM 
to the application program when the operator enters 
the K-display command: 

K. DU=appname 


Application NAH 


Message 


HOP/DB/R 


The program should begin using any debug code it contains. 


Application NAM 


The program can stop using any debug code it contains. 


Application NAM 


Message 


HOP/OE/R 


Message 


- HOP/DU/R 

The program should dump its field length and any extended central storage. 


Application NAM 


Message 

HOP/TRACE/R 


The program should begin using its debug log file. 


Application NAM 


The program can stop using its debug log file. 


Application NAM 


Message 


HOP/NOTR/R 


Message 


- HOP/REL/R 

This program should release its debug log file for postprocessing. 


Application NAM 


Message 


-HOP/RS/R 

The program should reinitialize and restart logging of all of its statistics. 


Figure 3-58. Host Operator Command Supervisory Message Sequences 
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ta 

hop 

db 

res 


ta 


59 


51 49 


43 


hop 


db 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code D0i6- access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 0Ei6- ^°u can access this field with the reserved symbol SFC, as 

described in section 4. Its value is the value of the reserved symbol DB. 

Reserved by CDC. 


Figure 3-59. Host Operator Request-to-Activate-Debug-Code <HOP/DB/R) Supervisory Message Format 


hop 

de 

res 

Figure 3-60. Host Operator Request-to-Turn-Off-Debug-Code (HOP/OE/R) Supervisory Message Format 



ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

hop Primary function code DO-i^- can access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

du Secondary function code 3. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is the value of the reserved symbol DU. 

res Reserved by CDC. 

Figure 3-61. Host Operator Request-to-Dump-Field-Length (HOP/DU/R) Supervisory Message Format 


59 51 49 43 0 



Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code D0i6- You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function OF-i^. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol DE. 

Reserved by CDC. 
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The application should dump its field length. The 
application can call NETDMB to dump its field length 
onto the AIP dump file ZZZZDMB (see section 6). 
There is no response to the request—to—dump-field— 
length message. 


The host operator request-to-turn-AIP-traffic- 
logging-on supervisory message (figure 3-62) is 
sent from NAM to the application program when the 
operator enters the K-display command: 

K.LB=appname 

The application program should call NETDBG to turn 
AIP logging on and begin logging of network traffic 
on the debug log file. (See section 6.) Note that 


the application program must be loaded with NETIOD 
for the AIP Logging to occur. There is no response 
to the request-to-turn-AIP-traffic-logging-on 
message. 

The host operator request-to-turn-AIP-traffIc- 
logging-off supervisory message (figure 3-63) is 
sent from NAM to the application program when the 
operator enters-the K-display command: 

K. LE=appname 

The application program should call NETDBG to turn 
AIP logging off and stop logging network traffic in 
its debug log file. (See section 6.) There is no 
response to the request-to-turn-AIP-traffic-logging- 
off supervisory message. 


59 

51 


49 

43 

0 

hop 

0 

0 

trace 

res 


ta 


hop 


trace 

res 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 2. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol TRACE. 

Reserved by COC. 


Figure 3-62. Host Operator Request-to-Turn-AIP-Traffic-Logging-On 
(HOP/TRACE/R> Supervisory Message Format 


59 

51 


49 

43 

0 

hop 

0 

0 

notr 

res 


ta 


hop 


notr 


res 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code 00^^. You can access this field"with-the reserved symbol PFC, as 
described in-,section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 7. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol NOTR. 

Reserved by COC. 


Figure 3-63. Host Operator Request-to-Turn-AIP-Traffic-Logging-Off 
(HOP/NOTR/R) Supervisory Message-Format 
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The host operator request-to-release-debug-log-flie 
supervisory message (figure 3-64) is sent from NAM 
to the application program when the operator enters 
the K-display command: 

K.LR=appname 

The application program should call NETREL to 
release the debug log file. To ensure proper 
processing of the debug log file, the application 
program must have issued a prior NETREL call as 
described in section 6. There is no response to 
the request-to-release-debug-log-file supervisory 
message. 

The host operator request-to-restart-statistics- 
gathering supervisory message (figure 3—65) is sent 
from NAM to the application program when the opera¬ 
tor enters the K-display command: 

K.RS=appname 


The application program should flush its statistics 
counters, reset them to zero, and restart statistics 
gathering. For this supervisory message to be 
useful the application program should do at least 
one of the following: 

Restart AIP statistics gathering by calling 
NETSTC (described in section 6) to turn AIP 
'■ statistics gathering off or back on. 

Restart any other statistical information 
internal to the application program that can be 
used to tune the particular application. The 
application program can write such statistical 
information onto the AIP statistical file 
ZZZZZSN by calling NETLGS (see section 6). 


There is no response to the request-to-restart- 
statlstics-gathering message. 


59 

51 


49 

43 

0 

hop 

0 

0 

rel 

res 


ta 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 


hop 


Primary function code DOi^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is the value of the reserved symbol HOP. 


re I 


Secondary function code You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is the value of the reserved symbol REL. 


res 


Reserved by COC. 


Figure 3-64. Host Operator Request-to-Release-Debug-Log-File (HOP/REL/R) Supervisory Message Format 


59 

51 


49 

43 

0 

hop 

0 

0 

rs 

res 


ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 


hop 


rs 


res 


Primary function code DO-i^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 8. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol RS. 

Reserved by CDC. 


Figure 3-65. Host Operator Request-to-Restart-Statistics-Gathering 
(HOP/RS/R) Supervisory Message Format 
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HOST OPERATOR INTERFACE 


Network applications can communicate with the host 
operator through the NAM K-dlsplay. This requires 
the application to be validated to use the NAM 
K-dlsplay. This is done by specifying the KDSP 
parameter in the APPL statement for the application 
in the local configuration file (see the Network 
Definition Language reference manual). 

Communication is done through the following 
supervisory messages: 


HOP Alert Supervisory 
Message (HOP/ALT) 

HOP Break Supervisory 
Message (HOP/BRK) 

HOP Command Supervisory 
Message (HOP/CMD) 

HOP Dayfile Supervisory 
Message (HOP/DAY) 

HOP Display Supervisory 
Message (HOP/DIS) 

HOP End Supervisory 
Message (HOP/END) 

HOP Ignore Supervisory 
Message (HOP/IG) 

HOP Log Supervisory 
Message (HOP/LG) 

HOP Page Supervisory 
Message (HOP/PAGE) 

HOP Start Supervisory 
Message (HOP/START) 


Application -> NAM 

Application <- NAM 

Application <- NAM 

Application -> NAM 

Application-> NAM 

Application <-NAM 

Application <- NAM 

Application -> NAM 

Application <- NAM 

Application <- NAM 


Initially, the application is not assigned the NAM 
K-dlsplay. In this state, the application can 
receive the HOP/IG supervisory message. This 
occurs when the host, operator informs the applica¬ 
tion that he no longer wishes to be informed of any 
alert conditions from this application. The appli¬ 
cation can also receive the HOP/START supervisory 
message. This occurs when the host operator 
assigns the K-dlsplay to this application. If the 


K-display is not assigned to the application, but 
the application needs to alert the host operator 
about an error condition, then the application 
should send the HOP/ALT supervisory message (unless 
the application has previously received a HOP/IG 
supervisory message, in which case the HOP/ALT 
supervisory message is discarded by NAM). 

When the K-dlsplay is assigned to the application, 
the application should Immediately respond with a 
HOP/DIS supervisory message to send data to the NAM 
K-display. Host operator entries are passed to the 
application through the HOP/CMD supervisory mes¬ 
sage. The application and the host operator can 
thus communicate with each other through the 
HOP/DIS and the HOP/CMD supervisory messages. If 
the host operator is no longer interested in seeing 
information that he requested, the host operator 
can type the break key in which case NAM sends a 
HOP/BRK supervisory message to inform the applica¬ 
tion, The application should then discontinue 
sending more data to the K-dlsplay and wait for the 
next operator command. 

Since the K-dlsplay interface does not provide any 
paging capability, the application is responsible 
for all paging. The HOP/PAGE supervisory message 
allows the host operator to inform the application 
when he wants paging turned on or off or when he 
wants to see the next page of data. 

When the host operator is no longer interested in 
communicating with the application, he terminates 
the K-display assignment to the application. When 
this occurs, the application receives a HOP/END 
supervisory- message. 

Whether the K-display is assigned to the 
application or not, the application that is 
validated for the NAM K-dlsplay can send messages 
to NAM's dayfile at any time. This is done by 
sending a HOP/LG supervisory message. 

The host operator alert supervisory message (figure 
3-66) is sent from the application to NIP when the 
application needs to provide the operator with 
information. If the application is not in Ignored 
status, NIP adds the application name to the 
K-display alert line. If the application is in 
Ignored status, NIP rejects the supervisory message 
and sends a host operator ignore supervisory 
(HOP/IG) message. There is no response to this 
message. 


59 

51 


49 

43 

0 

hop 

0 

0 

aLt 

res 


ta 


hop 


alt 


res 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code DO 15 , You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code B. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol ALT. 

Reserved by CDC. Reserved fields contain zero. 


Figure 3-66. Host Operator Alert CHOP/ALT/R) Supervisory Message Format 
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The host operator break supervisory message (figure 
3-67) is sent from NIP to the application program 
when the operator enters the break character at the 
console. If NIP was rejecting operator entries 
because the application has not yet responded to 
the previous operator entry, the application sends 
a HOP/DIS supervisory message to NIP with the 
input-allowed flag set and input is allowed again. 


The host operator command supervisory message 
(figure 3-68) is sent from NIP to the application 
when the operator enters a command on the K-dlsplay 
and the K-display is assigned to the application. 
This supervisory message contains the operator 
entry. The application must respond with a host 
operator K-display supervisory message before NIP 
allows any other operator entries except *, /, +, 
or -. 


The operating system records all K-display entries 
made by the .host operator into the NAM and system 
dayfiles. If a network application program that is 
communicating with the host operator does not want 
this to occur, the application program can send the 
host dayflle supervisory message (figure 3-69) to 
NIP with the dayfiling flag set to terminate 
recording of K-display entries. If the K-dispIay 
is not assigned to the application program when 
this supervisory message is sent, NIP Ignores the 
supervisory message. There is no response to this 
message. 

Hie network dayfile message supervisory message 
(figure 3-70) is sent from the application to NIP 
when the application wants to write a message into 
nip's job dayfile. There is no response to this 
message. The application program must be validated 
for K-display use in order for' NIP to accept this 
supervisory message. 


59 

51 

49 

43 

0 

hop 

0 

0 

brk 

res 


ta 

hop 

brk 

res 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code You jan access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 0. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol BRK. 

Reserved by CDC. Reserved fields contain zero. 


Figure 3-67. Host Operator Break (HOP/BRK/R) Supervisory Message Format 



59 

51 

49 

43 

17 0 

ta 

hop 

0 

0 

cmd 

res 

dtl 


message 


ta 

hop 

cmd 

res 

dtl 

message 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code OO-i^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 1. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol CMD. 

Reserved by CDC. Reserved fields contain zero. 

Character length of the operator typein. You can access this field with the reserved 
symbol DTL, as described in section 4. 

Operator input in display code, left-justified, and binary zero filled. 


Figure 3-68. Host Operator Command (HOP/CMD/R) Supervisory Message Format 
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59 


51 49 


43 


0 


ta 

hop 

day 

res 

f 


hop 


day 


res 



Symbolic address of the application program's text area receiving this asynchronous supervisory 
message. 

Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 10^^. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is the value of the reserved symbol DAY. 

Reserved by CDC. Reserved fields contain zero. 

Flag indicating whether K-display entries made by the host operator are recorded in the NAH and 
system dayfiles. This field has the following values: 


0 Turns off the dayfiling of K-display entries 
1 Turns on the dayfiling of K-display entries 


Figure 3-69. Host Dayfile CHOP/DAY/R) Supervisory Message Format 


ta 


59 

51 


49 

43 0 

hop 

0 

0 

Lg 

res 

text 


ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

hop Primary function code D0-|^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

Lg Secondary function code A^^. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is the value of the reserved symbol LG. 

res Reserved by CDC. Reserved fields contain zero. 

text Text of the dayfile message, 1- to 8-words in display code, right-justified and terminated 

with at least 12 bits of zero. 


Figure 3-70. Network Dayfile (HOP/LG/R) Supervisory Message Format 


The K-display supervisory message (figure 3-71) is 
sent from the application to NIP when the applica¬ 
tion has the K-dlsplay assigned to it and has data 
to send to the operator. NIP maintains a 32 line 
buffer for the application. Data messages sent by 
the application are always added to the bottom of 
the 32 line buffer. Older data messages are 
scrolled up until they disappear off the top of the 
screen. To clear the entire buffer, the applica¬ 
tion must send 32 lines. If the application does 
not have the K-display buffer assigned to it, NIP 
ignores the supervisory message. There is no 
response to the message. 


The host operator end display supervisory message 
(figure 3-72) is sent by NIP to inform the 
application that the K-display is no longer 
assigned to it. There is no response to this 
message. 

The host operator ignore supervisory message 
(figure 3-73) is sent from NIP to the application 
when the operator informs NAM that he no longer 
wishes to be informed about the application's 
requests for K-dlsplay service. If the application 
should send a HOP/ALT/U supervisory message to NIP 
anyway, NIP rejects it and sends another HOP/IG/U 
supervisory message to the, application. There is 
no response to this message. 
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ta 


hop 


dis 


ta 


data 

message 



Symbolic address of the application program's text area receiving this asynchronous superr 
visory message. 

Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 9. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol DIS. 

Reserved by CDC. Reserved fields contain zero. 

Screen flag indicating which screen the display message is on. This field can have the 
following values: 

0 Indicates the display message is on the left screen. 

1 Indicates the display message is on the right screen. 

Input allowed flag. This flag is set to 1 by the application when it is ready for further 
input from the host operator. NIP will reject all input from the host operator'until a 
HOP/DIS supervisory message is sent with the flag set. 

The data to be displayed on the K-display. This message must be in display code and can 
contain up to page length lines. Each line can contain a maximum of 60 characters and must 
be terminated by 1 to 5 zero bytes. The page length is specified on the HOP/START message 
for both the left and right screens of the K-display. 


Figure 3-71. Host Operator K-Display Data (HOP/DIS/R) 
Supervisory Message Format 


59 51 49 43 17 0 



ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

hop Primary function code DO^^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

end Secondary function code 6. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is the value of the reserved symbol END. 

res Reserved by CDC. Reserved fields contain zero. 

abn Application block number from the application block header of the last HOP/DIS/U supervisory 

message displayed by NIP. 


Figure 3-72. Host Operator End Display <H0P/END/R) 
Supervisory Message Format 
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59 


51 49 


43 


0 



Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code DOi^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 4. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol IG. 

Reserved by CDC. Reserved fields contain zero. 


Figure 3-73. Host Operator Ignore (HOP/IG/R) Supervisory Message Format 


The host operator page supervisory message (figure 
3-74) is sent from NIP to the application when the 
operator enters either of the characters + or - at 
the console. 


The host operator start supervisory message (figure 
3-75) is sent from NIP to the application when the 
operator assigns the K-display to the application. 
The application is then allowed to send messages 
via the HOP/DIS/C message to NAM's K-display. 
There is no response to this message. 



ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

hop Primary function code You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is the value of the reserved symbol HOP. 

page Secondary function code C.]^. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is the value of the reserved symbol PAGE. 

res Reserved by CDC. Reserved fields contain zero. 

pc Page character (+ or -) specified in display code. 

Figure 3-74. Host Operator-Page (HOP/PAGE/R) Supervisory Message Format 
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ta 


59 

51 

49 43 

23 

11 0 

hop 

0 

0 

start 

res 

lsize 

rsize 


ta 

hop 

start 


res 
Lsize 
rsi ze 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code DO-i^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is the value of the reserved symbol HOP. 

Secondary function code 5. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is the value of the reserved symbol START. 

Reserved by CDC. Reserved fields contain zero. 

Page length of the left screen. 

Page length of the right screen. 


Figure 3-75. Host Operator Start (HOP/START/R) Supervisory Message Format 

HOST SHUTDOWN 


Conditions sometimes require the host operator to 
terminate network operations or to abort the appli¬ 
cation program. The host operator can shut down 
the entire data communications network or portions 
of the network, element by element, including 
executing application programs. 

The operator has two shutdown options available. 
The operator can select an idle-down option that 
permits gradual termination of operations, usually 
as a normal part of network service. The operator 
can also select a disable option; this option 
requests Immediate termination of application pro¬ 
gram operations and can either follow selection of 
the idle-down option or be independently selected. 

The type of shutdown determines the shutdown proc¬ 
essing that should be performed by the application 
program. Figure 3—76 illustrates the three asyn¬ 
chronous supervisory message sequences that can 
occur during shutdown operations. The first 
sequence begins when an idle-down option is selec¬ 
ted; the application program receives an advisory 
shut-down message, shuts down its connections 
gracefully,and terminates network access without 
additional network or host operator action. The 
second sequence begins when a disable option is 
selected; the application program receives a man¬ 
datory shut-down message and should not attempt to 
terminate connections gracefully. The third 

sequence is a hybrid of the first two; if insuffi¬ 
cient time elapses between selection of an idle- 
down option and selection of a disable option, the 
application program can terminate some of its con¬ 
nections gracefully, but not all of them. 

The Network Access Method does not attempt to force 
the termination of applications that do not call 
NETOFF in response to an idle-down or disable 
request. Normal termination of network operations, 
however, depends on correct application behavior. 
Applications that do not eventually call NETOFF 
after receiving an idle or disable request must be 
dropped by the host operator. This then permits 
normal termination of the network software. 

Figure 3-77 shows the two forms of the host-shutdown 
supervisory message. The application program does 
not issue a response to this supervisory message. 


Application NAM 


Message 

SHUT/INSD/R 

(idle-down) 



- ► 


CON/END/R 

- 


CON/END/N 

The application program fetches all queued 
upline blocks from all terminals or other appli¬ 
cation programs, then ends all connections prior 
to a shutdown of the network. 

The application program 
the network with a call 
NETOFF. (See section 5 

can then disconnect from 
to the AIP routine 

.) 

Application NAM 


Message 



on LI 1 / X no 1 / / f\ 

(disable) 

The application program must perform an imme¬ 
diate call to NETOFF to avoid being aborted by 
system console operator commands during the 
network shutdown in progress. 

Application NAM 


Message 

SHUT/INSD/R 

(idle-down) 



- ^ 


CON/END/R 

- 


CON/END/N 

SHUT/INSD/R 

(disable) 



The application program fetches as many queued 
upline blocks as possible and ends as many 
connections as possible prior to shutdown of the 
network, then issues its NETOFF call immediately 
after receipt of the second shutdown message. 


Figure 3-76. Host Shutdown Supervisory 
Message Sequences 


3-78 
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59 

51 


49 

43 

0 

shut 

0 

0 

insd 

res 

i 


ta 


shut 


insd 


res 

i 


Symbolic address of the application program's text area receiving this asynchronous super¬ 
visory message. 

Primary function code 42^^. You can access this field with the reserved symbol PFC, as 
described in section 4. Its value is defined as the value of the reserved symbol SHUT. 

Secondary function code 6. You can access this field with the reserved symbol SFC, as 
described in section 4. Its value is defined as the value of the reserved symbol INSD. 

Reserved by CDC. 

Indicator for type of shutdown message. This field can have the values: 

0 This is a normal (warning) message of a pending network shutdown. The network 
software will not permit any more logical connections to be established, but the 
application program can inform existing connections of the shutdown, fetch queued 
input data from all connections, and voluntarily end all connections before 
issuing a NETOFF call. (See section 5.) 

1 Network shutdown is beginning. The application cannot send or receive blocks on 
any existing connection and no more logical connections can be established. The 
application program must issue a NETOFF call immediately without ending any 
existing connections. (See section 5.) 

You can access this field with the reserved symbol SHUTF as described in section 4. 


Figure 3-77. Host-Shutdown (SHUT/INSD/R) Supervisory Message Format 


ERROR REPORTING 

The primary mechanism used by the network software 
to Indicate logic errors to an application program 
is an asynchronous supervisory message. In all 
cases, the message sequence for this mechanism con¬ 
sists of a single message (figure 3-78). The mes¬ 
sage used in this sequence is the logical-error 
supervisory message, shown in figure 3-79. The 
application program does not send a response to 
this supervisory message. 


Application 

NAM 

Message 

^ - 


ERR/L6L/R 


Figure 3-78. Logical-Error Supervisory 
Message Sequence 

As indicated by the reason codes Included in the 
message, many conditions are considered to be 
logical errors by ..the- network software. The 
simpler conditions are completely defined within 
the figure; more details’are described here. 

The rc field value of 1 is received when: 


On an appllcatlon-to-device connection, an 
application character type other than 2, 3, or 
4 was used in a downline block header or in a 
change-input-character-type supervisory message. 

The rc field value of 4 is received when: 

The application connection number involved is 
out-of-range for the application program and 
therefore nonexistent. Connection numbers not 
yet assigned to the application program, or 
greater than maxacn, are out of range. 

Application connection number 0 is specified 
in a change-connection-list or turn-list- 
processing-off supervisory message. 

The rc field value of b is received when the 

application program is not using a flow control 
monitoring mechanism, such as that described 
earlier in this section. The downline block 
causing the block limit to be exceeded xs 

discarded. The application program should not 
transmit any more downline blocks until It has 
received at least one block-delivered message 
upline. 


On an appllcatlon-to-applicatlon connection, 
the application connection specified an 
application character type of 4 either in the 
application block header or in a change-input- 
character- type supervisory message. 

For a supervisory message the application 
specified an application character type other 
than 1, 2, or 3 in the application block header. 


The rc field value of 6 is received when the 
network software attempts to protect itself from 
application program flaws in supervisory message 
processing logic. A partial limit Imposed on the 
number of logical errors permitted for an appli¬ 
cation program prevents the application program 
from deadlocking the network in such cases. This 
limit applies only to logical-error messages queued 
for the application program. The limit keeps the 
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program from committing large numbers of errors In 
downline transmissions without periodically 
fetching asynchronous supervisory messages sent 
upline to identify the errors. The limit is 
implemented as follows: 

Each time the network software sends an asyn¬ 
chronous logical-error message to the applica¬ 
tion program, a limit counter for the program 
is incremented by one. 

Each time the application program fetches all 
queued asynchronous supervisory messages it has 
outstanding, the limit counter for the program 
is reset to zero. 


When the limit counter for the program reaches 
100, a logical-error message with the rc field 
value of 6 is queued for the program. Until 
the application program fetches all queued 
asynchronous supervisory messages it has out¬ 
standing, any downline transmission by the 
program that causes a logical-error message 
condition is discarded by the network software 
without being processed. 

When the limit counter reaches 100, additional 
asynchronous supervisory messages might already be 
buffered by AIP. In this case, the maximum number 
that must be fetched to clear the counter may be as 
high as 121. 



ta Symbolic address of the application program's text area receiving this asynchronous super¬ 

visory message. 

err Primary function code 84i^. You can access this field with the reserved symbol PFC, as 

described in section 4. Its value is defined as the value of the reserved symbol ERR. 

Igl Secondary function code 1. You can access this field with the reserved symbol SFC, as 

described in section 4. Its value is defined as the value of the reserved symbol LGL. 

rc Reason code identifying the cause of the message. This field can contain the values: 

1 An invalid act value was specified in the block header of a downline data block 
or in a OC/CICT/R message. 

2 An invalid tic was encountered; either the value in the block header of a 
downline block was greater than 2043, or the length of the block exceeded 410 
central memory words. 

3 An invalid abt value was specified in the block header of a downline block. 

The value was not 1, 2, 3, 6, or 7. 

4 An invalid acn value was encountered in the block header of a downline data block, 
in a synchronous supervisory message, or in an asynchronous supervisory message. 

5 The application block limit of the connection has been exceeded for downline 
transmissions. 

6 A total of 100 ERR/L6L/R and/or CON/ACRQ/A supervisory messages have been queued 
for the application program and have not been picked up by the application 
program. No more ERR/LGL/R or C0N/ACR9/A supervisory messages can be queued for 
the application program until all asynchronous supervisory messages are fetched 
by the application program. All downline messages which cause ERR/LGL/R or 
CON/ACRQ/A supervisory messages are ignored. 

7 An invalid or illogical asynchronous supervisory message was encountered; either 
the combined primary and secondary function codes of the message are not a valid 
value, or the message is not permitted as part of supervisory message sequences 
currently in progress with the application program, or a synchronous supervisory 
message was sent on connection 0. 


Figure 3-79. Logical-Error (ERR/LGL/R) Supervisory Message Format (Sheet 1 of 2) 
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res 

abherr 

f i rstwrd 


8 A fragmented input or output error has occurred; a call to NETPUTF, NETGETF, or 
NETGTFL causes this supervisory message when the block involved in the call con¬ 
tains more than 40 fragments, contains a fragment of more than 63 words, or the 
total block length in words is inconsistent with the call's tlmax parameter or 
the block header's tic value. 

9 Either a block of type 6 or 7 was sent on a device-to-application connection, a 
block of type 1 or 2 was sent after a block of type 6, or a block of type 6 or 7 
was sent after a block of type 1. 

10 An invalid tic was encountered; in this case, the value of the tic specified was 
less than the minimum size required for the supervisory message. 

12 An application is not allowed to send data blocks on a connection it has 
established with a passive device of device types 1 through 4. 

13 Reserved by CDC for network software use. 

thru 

15 

16 Reserved for the NAM subsystem. 

thru 

256 

You can access this field with the reserved symbol RC, as described in section 4. 

Reserved by CDC. 

Application block header word associated with the supervisory message that caused the 
ERR/LGL/R message. This field contains a non-zero word unless the rc value is 7. You can 
access this field with the reserved symbol ERRABH, as described in section 4. 

The first 60 bits of the supervisory message causing the ERR/LGL/R message are placed in this 
field if the network software can supply the information. This field contains a non-zero 
word unless the rc value is 7. You can access this field with the reserved symbol ERRMSG, as 
described in section 4. 


Figure 3-79. Logical-Error (ERR/LGL/R) Supervisory Message Format (Sheet 2 of 2) 
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USER PROGRAM INTERFACE DESCRIPTIONS 


4 


This section describes the language Interface 
requirements of an application program, the inter¬ 
facing utilities available to a program, and those 
aspects of network software Internal interfacing 
that affect program use of certain Network Access 
Method (NAM) features. However, this manual does 
not attempt to describe all network software inter¬ 
faces. Portions of the network software that exe¬ 
cute as application programs use supervisory mes¬ 
sages that are either not discussed in this manual 
or else that are modified from the format presented 
in this manual. This section treats only those 
areas of interface that are properly used by an 
installation-written application program. 

LANGUAGE INTERFACES 

Application program use of the Application Interface 
Program (AIP) is essentially independent of the 
language used to code the application program. 
Parameter list and calling sequence requirements 
are the same for COMPASS assembler language and 
compiler-level languages. The residence of the AIP 
routines, the form of the calling sequences, and 
the utilities available to the application program 
differ for COMPASS and compiler-level languages. 

PARAMETER LIST AND CALLING 
SEQUENCE REQUIREMENTS 

The AIP statements and interfacing utilities use 
FORTRAN-style calling sequences and parameter lists; 
that is, a parameter list contains one 60-bit word 
per parameter. The address of this parameter list 
is passed to the appropriate routine in register Al. 
Linkage with the statement within the application 
program is performed by executing a return jump 
instruction (RJ) to the entry point. To provide 
compact object code, traceback information is not 
generated, and the parameter list need not be fol¬ 
lowed by a word of zeros. 

Because the statement parameters are passed by 
address (called by reference), the NAM programmer 
should be careful about substituting values when 
defining the parameters. Those parameters identi¬ 
fied as return parameters should not be specified 
as constants or expressions in the call statement. 
Such specifications can produce unpredictable errors 
in program code. This restriction is compatible 
with normal FORTRAN programming practices. 

Return parameters are normally defined by variable 
names, array names, array element names, or similar 
symbolic addresses. Since the terminology for such 
entities varies according to the programming lan¬ 
guage used, this manual uses the term- symbolic 
address for all such possibilities. Unless other¬ 
wise stated, numeric absolute or relative addresses 
are not used in call statements. 


Those parameters identified as input parameters can 
be defined by constants, expressions that can be 
evaluated to produce constants, or symbolic 
addresses (as defined above). Input parameters are 
usually defined by constants or expressions; this 
manual uses the term value for all such possibil¬ 
ities. 

All AIP statement parameters used by a COBOL program 
must be described in the Data Division as level 01 
data entries, or data entries at other levels when 
the entries are left-justifled to word boundaries. 
COBOL 5 programs that access fields within param¬ 
eters must also describe the fields in the Data 
Division as COMP-4 numeric data entries to manipu¬ 
late values within the fields as 6-bit entities. 
Direct field access and AIP use is difficult using 
COBOL; COMPASS macros or FORTRAN subroutines are 
sometimes necessary to set up parameters before AIP 
calls or to unpack them after AIP calls. 

All direct calls from a COBOL program to AIP must 
be coded as calls to FORTRAN-X subroutines. Refer 
to section 5. Indirect use of AIP by a COBOL pro¬ 
gram is also possible; refer to the Queued Terminal 
Record Manager description later in this section. 

The AIP statement calling sequence does not permit 
recursive calls. 


PREDEFINED SYMBOLIC NAMES 

The fields in NAM supervisory messages of appli¬ 
cation character types 1 and 2 have been assigned 
symbolic names so that they can be identified to 
the utilities described later in this section. 
These names are display-coded Hollerith characters 
and are listed and defined in table 4-1. The 
capitalized symbol appears as it should be used in 
calls to NFETCH or NSTORE. The symbols are arranged 
alphabetically within the table. 

Each symbol consists of the characters identifying 
its field.within a message, combined with characters 
identifying the specific message or group of mes¬ 
sages. For example: 

All primary function code fields can be accessed 
through the symbol "PFC. 

All fields in messages with the primary func¬ 
tion code mnemonic CON begin with CON; the 
application list number field in such messages 
is therefore CONALN. 

All fields in the application block header word 
can be accessed through symbols beginning with 
ABH. 
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Some symbols are restricted to use In certain con¬ 
texts. For example, the FORTRAN 5 call: 

IVAL=NFETCH(0,L"CONEND") 

returns the primary and secondary code value for 
the corresponding fields in a CON/END/R message; 
however, the FORTRAN 5 call: 

CALL NST0RE(SMTA,L"C0NEND",1VAL) 

causes an error message indicating that the symbol 
CONEND is unrecognized. The symbol is unrecognized 
because its context is incorrect. The correct 
FORTRAN call to store the information is: 

CALL NSTORE(SMTA,L"PFCSFC",IVAL) 

or the call: 

CALL NSTORE(SMTA,L"PFCSFC",L"C0NEND") 

There are no predefined names for the AIP statement 
parameters described in section 5. 


PREDEFINED SYMBOLIC VALUES 

Some of the supervisory message fields with pre¬ 
defined symbolic names have predefined values that 
can be obtained through the utilities described 
later in this section. Values for such names are 
given in table 4-1, where the names are listed 
alphabetically. 

You can obtain the value assigned to a given sym¬ 
bolic name in the released version of the network 
software by using a form of the NFETCH utilities. 
The NFETCH utilities comprise a macro that can be 
called by a COMPASS program, and a similar subrou¬ 
tine that can be called by a program written in a 
high-level language. 

Be careful in using names with predefined values; 
in some instances, a name and corresponding value 
have been assigned to a group of fields. Choosing 
a wrong name in a utility call can fill more fields 
than the programmer intends. The NAM programmer 
should become familiar with all of the predefined 
symbolic names before using the interfacing utili¬ 
ties . 


COMPASS ASSEMBLER LANGUAGE 

Application programs coded in COMPASS use AIP 
statements that make macro calls. These AIP macros 
reside in the system text library NETTEXT. 

Packing and unpacking supervisory message blocks in 
a COMPASS program is easily accomplished using the 
Interfacing utilities NFETCH' and NSTORE. These 
field access utilities also reside in the system 
text library NETTEXT. An application program using 
either utility must first contain calls to SST and 
NETMAC. 


Application Interface Program Macro 
Call Formats 

For those AIP statement calls with parameters, three 
forms of the COMPASS macro call are possible: 

[label] macro-name parameters 

This is the format of the standard call, 
which produces the full calling sequence. 

[labell] macro-name (LIST=label2 • \ 

lLIST=reglster name/ 

When this format is used, macro expansion 
assumes that the proper calling parameter 
block is located at the address specified 
by the LIST value, loads this address into 
register Al, and performs the call to the 
AIP procedure. 

Iabel2 macro-name parameters, LIST 

When this format is used, macro expansion 
produces a parameter block in place but 
does not generate the call to the AIP pro¬ 
cedure; the address of the statement using 
this form is the address used in the second 
form. 

Use the first form when making a straightforward 
call to the AIP procedures. Use the second form 
once the parameter list has been created elsewhere 
with the third form. The second and third forms 
save space when procedures are used several times. 

Example 1: 

NETPUT IHA.ITA 

This statement is a direct call to execute the 
NETPUT macro with the two symbolic address param¬ 
eters shown. 

Example 2: 

PUTl NETPUT IHA,ITA,LIST 

This statement expands the NETPUT macro and creates 
the indicated parameter list at symbolic address 
PUTl but does not execute NETPUT. 

Example 3: 

NETPUT LIST=PUT1 

This statement actually executes the NETPUT macro 
with the parameters in the list expanded at location 
PUTl. 

If a macro call is issued with an error, the COMPASS 
assembler flags the error and provides an explana¬ 
tion during assembly of the macro. A complete 
listing of the assembly error messages from AIP- 
related macros is provided in appendix B. 

A summary of all the macro call formats available 
appears in appendix D. 
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TABLE 4-1, RESERVED SYMBOLS 


Symbol 

Entity Defined by Symbol 

Predefined 
Integer Value 

ABHABN 

Application block number field in application block header for all upline or 
downline blocks 

None 

ABHABT 

Application block type field in application block header for all upline or 
downl Ine bl ocks 

None 

ABHACT 

Application character type field In application block header for all upline 
or downllne blocks 

None 

ABHADR 

Process number address field Jn application block header for supervisor pro¬ 
gram upline or downline blocks (system use only). Application connection 
number field in application block header for all application program upline 
or downline blocks. 

None 

ABHBIT 

Parity error flag bit in application block header for upline (input) blocks. 
Auto-input mode flag bit in application block header for downline (output) 
bl ocks. 

None 

ABHCAN 

Cancel previous blocks bit in application block header for upline (input) 
blocks. Punch banner, (lace) card bit in application block header for down¬ 
line (output) blocks. 

None 

ABHIBU 

Input block undeliverable bit in application block header for upline (input) 
blocks 

None 

ABHNCP 

No cursor positioning flag bit in application block header for downline 
(output) blocks. 

None 

ABHNEP 

No echoplex flag bit in application block header for downline (output) 
blocks. 

None 

ABHNFE 

No format effectors flag bit in application block header for downline (out¬ 
put) blocks 

None 

ABHTLC 

Text-length-in-character-units field in application block header for all 
upline or downline blocks 

None 

ABHTRU 

Truncation occurred bit in the application block header for upline (input) 
data or supervisory message blocks 

None 

ABHWORD 

Application block header word for all upline or downline blocks 

None 

ABHXPT 

Transparent mode transmission bit in application block header for all upline 
or downline blocks 

None 

ACCOM 

Application character type of CON supervisory messages, for use in applica¬ 
tion block header 

1 

ACCTRL 

Application character type of CTRL supervisory messages, for use in applica¬ 
tion block header 

2 

ACDBG 

Application character type of DBG supervisory messages, for use in applica¬ 
tion block header 

1 

ACDC 

implication character type of DC supervisory messages, for use in applica¬ 
tion block header 

1 

ACERR 

Application character type of ERR supervisory messages, for use in applica¬ 
tion block header 

1 

ACFC 

Application character type of FC supervisory messages,. for use in applica¬ 
tion block header 

1 

ACHOP 

Application character type of HOP supervisory messages, for use in applica¬ 
tion block header 

1 

ACIFC 

Application character type of IFC supervisory messages, for use in applica¬ 
tion block header 

1 
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TABLE 4-1. RESERVED SYMBOLS (Contd) 


Symbol 

Entity Defined by Symbol 

Predefined 
Integer Value 

ACINTR 

Application character type of INTR supervisory messages, for use In applica¬ 
tion block header 

1 

ACK 

Secondary function code field for FC/ACK/R 

2 

J ACLST 

Application character type of LST supervisory messages, for use In applies- • 
tlon block header 

1 

ACRQ 

Secondary function code field for CON/ACRQ messages 

2 

AC SET 

Application character type of SET supervisory messages, for use in applica¬ 
tion block header 

1 

ACSHOT 

Application character type of SHUT supervisory messages, for use in applica¬ 
tion block header 

1 

ACTCH 

Application character type of TCH supervisory messages, for use in applica¬ 
tion block header 

1 

ALT 

Secondary function code field in HOP/ALT/R 

B 

APP 

Secondary function code field for INTR/APP/R 

2 

BI 

Primary function code field for BI/MARK/R 


BIMARK 

Primary and secondary function code fields for BI/MARK/R, Including EB and 

RB fields as zero 

CAOO- ^ 
lo 

BRK 

Secondary function code field for FC/BRK/R and HOP/BRK/R 

0 

CB 

Secondary function code field for CON/CB/R 

5 

CCD 

Secondary function code field for CON/CCD/R 

°^16 

CHAR 

Secondary function code field for CTRL/CHAR/R 

»16 

CICT 

Secondary function code field for DC/CICT/R 

0 

CMD 

Secondary function code field in HOP/CMD/R 

1 

CON 

Primary function code field for connection management (CON) supervisory messages 


CONAABL 

Application block limit field in CON/ACRQ/R 

None 

CONABN 

Application block number field of CON/REQ/R 

None 

CONAABN 

Application block number field of CON/ACRQ/R 

None. 

CONAAWC 

User validation control word in CON/REQ/R 

None 

CONABL 

Application block limit field in CON/REQ/R 

None 

CONABN 

Application block number field of CON/ACRQ/R 

None 

CONABZ 

Block size in connection management (CON) supervisory messages 

None 

CONACN 

Application connection number field in connection management (CON) 
supervisory messages 

None 

CONACR 

Primary and secondary function code fields for CON/ACRQ/R, including EB and RB 
fields as zero 

6302^^ 

CONACRA 

Primary and secondary function code fields in CON/ACRQ/A including EB field 
set to 1 

6382,^ 

1 D 
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TABLE 4-1. RESERVED SYMBOLS (Contd) 


Symbol 


Entity Defined by Symbol 


CONACT 

CONADBL 

CONADBZ 

CONAHDS 


Application input character type field in CON/REQ/N 
Downline block limit field in CON/ACRQ/R 
Downline block size field In CON/ACRQ/R 
User validation control word in CON/REQ/R 


Predefi ned 
Integer Value 

None 

None 

None 

None 
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TABLE 4-1. RESERVED SYMBOLS (Contd) 


Symbol 

Entity Defined by Symbol 

Predefined 
Integer Value 

CONAHMT 

User validation control word in CON/REQ/R 

None 

CONAHWS 

User validation control word in CON/REQ/R 

None 

CONALID 

Logical identifier field in CON/ACRQ/R 

None 

CONALN 

Application list number field in CON/REQ/N 

None 

CONANM 

Requesting application program name in CON/REQ/R 

None 

CONANM2 

NAME2 outcall identifier field in CON/ACRQ/R 

None 

CONAPRI 

Priority flag field in CON/ACRQ/R 

None 

CONATWD 

User validation control word in CON/REQ/R 

None 

CONAUBL 

Upline block limit field in CON/ACRQ/R 

None 

CONAUBZ 

Upline block size field in CON/ACRQ/R 

None 

CONAUDL 

Length of call user data in CON/ACRQ/R 

None 

CONAWS 

Send window size field in CON/ACRQ/R 

None 

CONCB 

Primary and secondary function code fields for CON/CB/R, including EB and RB 

6305^^ 


fields as zero 


CONDBZ 

Downline block size in CON/REQ/R 

None 

CONDPLS 

Send data packet length in CON/ACRQ/R 

None 

CONDT 

Device type field in CON/REQ/R 

None 

CONEND 

Primary and secondary function code fields in CON/END/R, including EB and RB 

6306^^ 


fields as zero 


CONENDN 

Primary and secondary code fields in CON/END/N Including RB field set to 1 

6346^^ 

CONFACN 

Number of facility groups in CON/ACRQ/R 

None 

CONFAM 

Login family name field in CON/REQ/R 

None 

CONFO 

Login family ordinal field in CON/REQ/R 

None 

CONHID 

Host node field in CON/REQ/R 

None 

CONICT 

Application input character type field in CON/REQ/N 

None 

CONLOAN 

Loaned connection status field in CON/REQ/R, CON/CB/N, and CON/END/R 

None 

CONNET 

Network type field in CON/REQ/R 

None 

CONNXP 

No transparent data field in CON/REQ/N 

None 

CONORD 

Device ordinal field in CON/REQ/R 

None 

CONOWNR 

Terminal name field in CON/REQ/R 

None 

CONPAR 

First word of parameters in CON/REQ/R 

None 

CONPL 

Page length field in CON/REQ/R 

None 

CONPW 

Page width field in CON/REQ/R 

None 

CONR 

Restricted interactive capability field in CON/REQ/R 

None 

CONRAC 

Reason code field in CON/REQ/N and CON/REQ/A 

None 
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TABLE 4-1.- RESERVED SYMBOLS (Contd) 


Symbol 

Entity Defined by Symbol 

Predefined 
Integer Value 

CONRCB 

Reason code field In CON/CB/R 

None 

CONREQ 

;P-rimary and secondary function code fields in CON/REQ/R, including EB and RB 
fields as zero 

6300, 

lb 

CONREQA 

Primary and secondary function code fields in CON/ACRQ/A including EB field 
set to 1 

- . 5380. . 

I 0 

CONREQN 

Primary and secondary function code fields in CON/REQ/N including RB field 
set to 1 

6340^^ 

CONSCT 

Synchronous message type field in CON/REQ/R 

None 

CONSDT 

Subdevice type field in CON/REQ/R 

None 

CONSL 

Security limit field in CON/REQ/R 

None 

CONT 

Terminal class field in CON/REQ/R 

None 

CONTNM 

Terminal name field in CON/REQ/R 

None 

CONUBZ 

Upline block size in CON/REQ/R 

None 

CONUDL 

Length of call user data in CON/REQ/R 

None 

CONUI 

User index field in CON/REQ/R 

None 

CONUSE 

User name field in CON/REQ/R 

None 

CONXBZ 

Transmission block size field in CON/REQ/R 

None 

CTRCHAR 

Primary and secondary function code fields in CTRL/CHAR/R, including EB and RB 
fields as zero 

Ci08^^ 

CTRCTD 

Primary and secondary function code fields in CTRL/CTD/R, including EB and RB 
fields as zero 


CTRDEF 

Primary and secondary function code fields in CTRL/DEF/R, Including EB and RB 
fields as zero 

C104^^ 

CTRL 

Primary function code field in terminal control (CTRL) supervisory messages 


CTRLCCD 

Primary and secondary function code fields for CTRL/CCD/R, including EB and RB 
fields as zero 

CIOC,, 
lb 

CTRLRCC 

Primary and secondary function code fields for CTRL/RCC/R, including EB and RB 
fields as zero 

ClOB,, 
io 

CTRRTC 

Primary and secondary function code fields for GTRL/RTC/R, including EB and RB 
fields as zero 

C109^^ 

CTRTCD 

Primary and secondary function code fields in CTRL/CHAR/R, including EB and RB 
fields as zero 

ClOA,, 

16 

DAY 

Secondary function code field In HOP/DAY/R 

10 

DB 

Secondary function code field in HOP/DB/R 

"lb 

DC 

Primary function code field in DC/CICT/R 


DCACN 

Application connection number field in DC/CICT/R or DC/STMR/R 

None 

DCACT 

Application character type field in DC/CICT/R 

None 

DCCICT 

Primary and secondary function code fields in DC/CICT/R, including EB and RB 
fields as zero 

C200., 

Id 
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TABLE 4-1. RESERVED SYMBOLS (Contd) 


Symbol 

Entity Defined by Symbol 

Predefined 
Integer Value 

DCNXP 

No transparent data field in DC/CICT/R 

None 

DCPERMT 

Permanent timer change field in DC/STMR/R 

None 

DCSCT 

Synchronous message character type field in DC/CICT/R 

None 

DCSTMR 

Primary and secondary function code fields in DC/STMR/R, including EB and RB 
fields as zero 

C202,, 
io 

DCTIME 

Time field in DC/STMR/R 

None 

DCTRU 

Primary and secondary function code fields in DC/TRU/R, including EB and RB 
fields as zero 

C201i6 

DE 

Secondary function code field in HOP/DE/R 

>'16 

DEFF 

Secondary function code field in CTRL/DEF/R 

4 

DIS 

Secondary function code field in HOP/DIS/R 

9 

DU 

Secondary function code field in HOP/DU/R 

3 

EB 

Error bit in all supervisory messages 

None 

ENDD 

Secondary function code field in CON/END/R and HOP/END/R 

6 

ERR 

Primary function code field in ERR/LGL/R 

8^6 

ERRABH 

Application block header word in ERR/LGL/R 

None 

ERRLG 

Reason code field in ERR/LGL/R 

None 

ERRLGL 

Primary and secondary function code fields in ERR/LGL/R, Including EB and RB 
fields as zero 

8401^6 

ERRMSG 

First message text word in ERR/LGL/R 

None 

FC 

Primary function code field in flow control (FC) supervisory messages 

8^16 

FCACK 

Primary and secondary function code fields in FC/ACK/R, Including EB and RB 
fields as zero 

830216 

FCACN 

Application connection number field in flow control (FC) supervisory messages 

None 

FCBRK 

Primary and secondary function code fields in FC/BRK/R, including EB and RB 
fields as zero 

8300i6 

FCINA 

Primary and secondary function code fields in FC/INACT/R, including EB and RB 
fields as zero 

830^6 

FCINIT 

Primary and secondary function code fields in FC/INIT/R, including EB and RB 
fields as zero 

8307^^ 

FCINITN 

Primary and secondary function code fields in FC/INIT/N including RB field 
set to 1 

8347^^ 

FCNAK 

Primary and secondary function code fields in FC/NAK/R, including EB and RB 
fields as zero 

8303,, 

10 

FCRBR 

Reason code field in FC/BRK/R 

None 

FCRST 

Primary and secondary function code fields in FC/RST/R, including EB and RB 
fields as zero 

8301i6 

FCUTF 

User specified timeout field in FC/INACT/R 

None 
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TABLE 4-1. RESERVED SYMBOLS (Contd) 


Symbol 

Entity Defined by Symbol 

Predefined 
Integer Value 

FDX 

Secondary function code field In LST/FDX/R 

3 

HDX 

Secondary function code field in LST/HDX/R 

4 

HOP 

Primary function code field in host operator (HOP) supervisory messages 


HOPALT 

Primary and secondary function code fields in HOP/ALT/R, including EB and RB 
fields as zero 

DOOB 

HOPBN 

Application-block-number field in HOP/END/R 

None 

HOPBRK 

- Primary and secondary function code fields in HOP/BRK/R, including EB and RB 
fields as zero 

DOOO 

HOPOID 

Primary and secondary function code fields in HOP/CMD/R, Including EB and RB 
fields as zero 

DOOl 

HOPDAY 

Primary and secondary function code fields in HOP/DAY/R, including EB and RB 
fields as zero 

DOlO 

HOPDAYF 

Dayfiling-flag field in HOP/DAY/R 

None 

HOPDB 

Primary and secondary function code fields in HOP/DB/R, Including EB and RB 
fields as zero 

bOOE., 

lo 

HOPDE 

Primary and secondary function code fields in HOP/DE/R, Including EB and RB 
fields as zero 

DOOF,, 
lo 

HOPDIS 

Primary and secondary function code fields in HOP/DIS/R, including EB and RB 
fields as zero 

D009 

HOPDTL 

Operator-coramand-length-in-dlsplay-code-units field in HOP/CMD/R 

None 

HOPDU 

Primary and secondary function code fields in HOP/DU/R, including EB and RB 
fields as zero 

D003,. 

lb 

HOPENDD 

Primary and secondary function code fields in HOP/END/R, Including EB and RB 
fields as zero 

D006 

HOPI 

Input-allowed-flag field in HOP/DIS/R 

None 

HOPIG 

Primary and secondary function code fields in HOP/IG/R, including EB and RB 
fields as zero 

D004 

HOPLG 

Primary and secondary function code fields in HOP/LG/R, including EB and RB 
fields as zero 

DOOA 

HOPLPL 

Left-screen-size-in-dlsplay-code-units field in HOP/CMD/R 

None 

HOPNOTR 

Primary and secondary function code fields in HOP/NOTR/R, including EB and RB 
fields as zero 

D007^^ 

HOPPAGE 

Primary and secondary function code fields in HOP/PAGE/R, including EB and RB 
fields as zero 

DOOC 

HOPPC 

Page-character field in HOP/PAGE/R 

None 

HOPREL 

Primary and secondary function code fields in HOP/REL/R, Including EB and RB 
fields as zero 

DOODj^ 

HOPRPL 

Right-screen-size-ln-display-code-units field in HOP/CMD/R 

None 

HOPRS 

Primary and secondary function code fields in HOP/RS/R, including EB and RB 
fields as zero 

DOOSjg 

HOPSCR 

Right—screen-data-flag field in HOP/DIS/R 

None 
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Symbol 

Entity Defined by Symbol 

Predefined 
Integer Value 




HOPSTRT 

Primary and secondary function code fields in HOP/START/R, including EB and RB 
fields as zero 

D005 

HOPTRCE 

Primary and secondary function code fields in HOP/TRACE/R, including EB and RB 
fields as zero 

0002,^ 

10 

IG 

Secondary function code field in HOP/IG/R 

4 

IHACT 

Secondary function code field in FC/INACT/R 

4 

INIT 

Secondary function code field in FC/INIT/R 

7 

INSD 

Secondary function code field in SHUT/INSD/R 

6 

INTR 

Primary function code field in user-interrupt (INTR) supervisory messages 

«°16 

INTRACN 

Application connection number field in user-interrupt (INTR) supervisory 
messages 

None 

INTRAPP 

Primary and secondary function code fields in INTR/APP/R, including EB and RB 
fields as zero 

BOOZ^^ 

INTRCHR 

Field containing ASCII alphabetic character A through Z in typeahead priority 
data user-interrupt supervisory messages 

None 

INTRRSP 

Primary and secondary function code fields in INTR/RSP/R, including EB and 

RB fields as zero 

B001i6 

INTRUSR 

Primary and secondary function code fields in INTR/USR/R, including EB and 

RB fields as zero 

aooo,^ 

io 

LCONAC 

Length in 60-bit words of CON/ACRQ supervisory messages 

2 

LCONACA 

Length In 60 bit words of CON/ACRQ/A 

2 

LCONCB 

Length in 60-bit words of CON/CB/R 

1 

LCONEN 

Length in 60-blt words of CON/END/R 

2 

LCONENN 

Length in 60 bit words of CON/END/N 

1 

LCONREQ 

Length in 60-bit words of CON/REQ/R message 

10 (Aj^) 

LCORQR 

Length in 60-bit words of CON/REQ/N and CON/REQ/A 

1 

LCTRL 

Length in 60-bit words of terminal control (CTRL) supervisory messages 

2 

LDC 

Length in 60-blt words of DC/CICT/R 

1 

LERR 

Length in 60-bit words of ERR/LGL/R 

J 

LFC 

Length in 60-blt words of flow control (FC) supervisory messages (except FC/BRK) 

1 

LFCACK 

Length in 60-bit words of FC/ACR/R 

1 

LFCBRK 

Length in 60-bit words of FC/BRK/R 

2 

LFCINCT 

Length in 60-blt words of FC/INACT/R 

1 

LFCINIT 

Length in 60-bit words of FC/INIT/R 

1 

LFCINITN 

Length in 60-bit words of FC/INIT/N 

1 

LFCNAK 

Length in 60-blt words of FC/NAK/R 

1 
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Symbol 

Entity Defined by.Symbol 

Predefined 
Integer Value 

LFCRST 

Length in 60-blt words of FC/RST/R 

1 

LG 

Secondary function code field in HOP/LG/R 

*16 

LGL 

Secondary function code field in ERR/LGL/R 

1 

LHOPAGE 

Length in 60-bit words of HOP/PAGE/R 

1 

LHOPALT 

Length in 60-bit words of HOP/ALT/R 

1 

LHOPBRK 

Length in 60-bit words of HOP/BRK/R 

1 

LHOPDAY 

Length in 60-bit words of HOP/DAY/R 

1 

LHOPDB 

Length in 60-bit words of HOP/DB/R 

1 

LHOPDE 

Length in 60—bit words of HOP/DE/R 

1 

LHOPDU 

Length in 60-bit words of HOP/DU/R 

1 

LHOPEND 

Length in 60-bit words of HOP/END/R 

1 

LHOPIG 

Length in 60-blt words of HOP/IG/R 

1 

LHOPNTR 

Length in 60-bit words of HOP/NOTR/R 

1 

LHOPREL 

Length in 60-bit words of HOP/REL/R 

1 

LHOPRS 

Length in 60-bit words of HOP/RS/R 

1 

LHOPSTR 

Length in 60-bit words of HOP/START/R 

1 

LHOPTRA 

Length in 60-bit words of HOP/TRACE/R 

1 

LINTR 

Length in 60-bit words of INTR/USR/R and INTR/RSP/R 

1 

LLST 

Length in 60-bit words of list management (LST) supervisory messages 

1 

LSHUT 

Length in 60-bit words of SHUT/INSD/R 

1 

LST 

Primary function code field in list management (LST) supervisory messages 

'^°16 

LSTACN 

Application connection number field in list management (LST) supervisory messages 

None 

LSTALN 

Application list number field in list management (LST) supervisory messages 

None 

LSTDIS 

Initial half duplex field in LST/HDX/R 

None 

LSTFDX 

Primary and secondary function code fields in LST/FDX/R, including EB and RB 
fields as zero 

C00J16 

LSTHDX 

Primary and secondary function code fields in LST/HDX/R, including EB and RB 
fields as zero 

C004^^ 

LSTOFF 

Primary and secondary function code fields in LST/OFF/R, including EB and RB 
fields as zero 

cooo,. 

io 

LSTON 

Primary and secondary function code fields in LST/ON/R, including EB and RB 
fields as zero 

COOli^ 

LSTSWH 

Primary and secondary function code fields in LST/SWH/R, including EB and RB 
fields as zero 

C002^g 

LTCH 

Length in 60-bit words of TCH/TCHAR/R 

1 
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Entity Defined by Symbol 

Predefined 
Integer Value 

MARK 

Secondary function code field In TO/MARK/R, BI/MARK/R, and RO/MARK/R 

0 

NAK 

Secondary function code field In FC/NAK/R 

3 

NOTR 

Secondary function code field In HOP/NOTR/R 

7 

OFF 

Secondary function code field in LST/OFF/R 

1 

ONN 

Secondary function code field in LST/ON/R and PRU/ON supervisory messages 

0 

PAGE 

Secondary function code field in HOP/PAGE/R 

C 

PFC 

Primary function code field in all supervisory messages 

None 

PFCSFC 

Primary and secondary function code fields in all supervisory messages, including 
EB and RB fields 

None 

RB 

Response bit in all supervisory messages 

None 

RC 

Reason code field in all supervisory messages 

None 

RCC 

Secondary function code field in CTRL/RCC/R 

®16 

REL 

Secondary function code field in HOP/REL/R 

“16 

REQ 

Secondary function code field in CON/REQ messages 

0 

RO 

Primary function code field in RO/MARK/R 

CB, 

lb 

ROMARK 

Primary and secondary function code fields in RO/MARK/R, including EB and RB 
fields as zero 

CBOO,, 

ib 

RS 

Secondary function code field in HOP/RS/R 

«16 

RSP 

Secondary function code field in INTR/RSP/R 

1 

RST 

Secondary function code field in FC/RST/R 

1 

RTC 

Secondary function code in field in CTRL/RTC/R 

’l6 

SFC 

Secondary function code field in all supervisory messages 

None 

SHUINS 

Primary and secondary function code fields in SHUT/INSD/R, including EB and RB 
fields as zero 

4206^^ 

SHUT 

Primary function code field in SHUT/INSD/R 


SHUTF 

Shutdown type field in SHUT/INSD/R 

None 

SPMSGO 

thru 

SPMSG9 

The corresponding word zero through nine of any supervisory message 

None 

START 

Secondary function code field in HOP/START/R 

5 

STMR 

Secondary function code field in DC/STMR/R 

02 

SWH 

Secondary function code field in LST/SWH/R 

2 

TCD 

Secondary function code field in CTRL/TCD 

*^16 

TCH 

Primary function code field in TCH/TCHAR/R 
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Symbol 

Entity Defined by Symbol 

Predefined 
Integer Value 

TCHACN 

Application connection number field in TCH/TCHAR/R 

None 

TCHAR 

Secondary function code field in TCH/TCHAR/R 

0 

TCHPL 

Page length field in TCH/TCHAR/R 

None 

TCHPW 

Page width field in TCH/TCHAR/R 

None 

TCHTCH 

Primary and secondary function code fields in TCH/TCHAR/R, including EB and RB 
fields as zero 

64001^ 

TCHTCL 

Terminal class field in TCH/TCHAR/R 

None 

TO 

Primary function code field in TO/MARK/R 

"S6 

TOMARK 

Primary and secondary function code fields in TO/MARK/R, including EB and RB 
fields as zero 

0400.. 

lo 

TRACE 

Secondary function code field in HOP/TRACE/R 

2 

USR 

Secondary function code field in INTR/USR/R 

0 
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Field Access Utilities 


Example 1: 


Two additional macros, NFETCH and NSTORE, are 
provided to make message field definition and access 
easier. Application programmers are urged to use 
these macros as described below. Use of these 
macros and their related predefined symbolic names 
will simplify application program conversion under 
future versions of the network software. 


MFETCH Macro 

A call to the NFETCH macro returns the contents of 
a specific field within an array of one or more 
words that comprise all or part of a supervisory 
message block. The octal Integer value returned by 
the call is right-justified within the X or 8 
register specified in the call. 

The format of the NFETCH macro call is given in 
figure 4-1, 


LOCATION 1 OPERATION ] VARIABLE 

[label] 

label 

1 NFETCH 1 array.field.Xj or Bj 

Optional address label of the macro call. 

array 

The address of the first word of the array from 
which the field value should be obtained. This 
parameter can be: 


An address label 

The name of a register address 

Zero 


If zero is declared, any predefined value for the 
indicated symbolic name is returned. 

field 

The predefined symbolic name of the field for 
which a value should be fetched from the array. 

The possible contents of field are listed 
alphabetically in table 4-1. 

I 

The number of the X or B register which 
should receive the value fetched from the 
array. The value is right-justified in Xj or 

Bj on return from the call. When a B 
register is used, the field to be fetched must 
be < 18 bits long. 


Figure 4-1. NFETCH Macro Call Format 


Execution of NFETCH destroys the contents of regis¬ 
ters A5, X5, X6, and the X or B register specified 
to receive the returned value. Execution of NFETCH 
requires the application program to contain calls 
to SST and NETMAC. Placing NETTEXT in the COMPASS 
control statement defines the NFETCH macro and the 
symbolic names used as the NFETCH field parameters. 

As examples of NFETCH use, consider the following 
operations. 


NFETCH MYARRAY,PFC,X1 

This statement places the value of the primary 
function code field within MYARRAY into register XI. 
The primary function code field Is identified by 
the symbolic name PFC. 


Example 2: 

SX2 BUFFER 

NFETCH X2,SFC,X3 

These statements place the value of the secondary 
function code field within BUFFER into register X3. 
The secondary function code field Is identified by 
the symbolic name SFC, and the address label BUFFER 
Is supplied through register X2. 


Example 3: 

NFETCH ARRAY,EB,X3 

NZ X3,ERROR 

These statements place the value of the error bit 
(EB) within ARRAY into register X3. If the value 
in X3 Is nonzero (if EB has a value of 1), a Jump 
to ERROR occurs. 


Example 4: 

NFETCH 0,CON,XI 

This statement returns the predefined value 63jg 
in register XI. The value returned is that of the 
primary function code field of all connection- 
request supervisory messages, as identified by the 
predefined symbolic name CON. 

If an NFETCH macro call Is Issued with an error, 
the COMPASS assembler flags the error and provides 
an explanation during assembly of the macro. A 
complete listing of the assembly error messages 
from NFETCH Is included In appendix B. 


NSTORE Macro 

A call to the NSTORE macro sets the contents of a 
specific field within an array of one or more words 
that comprise all or part of a supervisory message 
block. The format of the NSTORE macro call is given 
in figure 4-2. 


Execution of NSTORE destroys the contents of 
registers A5, A6 ,-X5, X6, X7, and any X or B regis¬ 
ter specified In the call. Execution of NSTORE 
requires the application program to contain calls 
to SST and NETMAC. Placing NETTEXT In the COMPASS 
control statement defines the NSTORE macro and the 
symbolic names used as the NSTORE field-parameters, 
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LOCATION 

OPERATION 

VARIABLE 

[label] 

NSTORE 

i array,field=value 


label Optional address label of the macro call. 

array The address of the first word of the array into 
which the field value should be placed. This 
parameter can be declared as an address label 
or the name of an address register. 

field The predefined symbolic name of the field for 

which a value should be stored in the array. The 
possible contents of field are listed alphabetically 
in table 4-1. 

value The value to be stored in the identified field 
within the array. This parameter can be: 

A right-justified integer 
A right-justified, zero-filled character string 

A symbolic name with a predefined value 
(see table 4-1) 

Bj or Xj, where j is the number of an X 
or B register containing one of the first 
two possibilities for value above. 


Figure 4-2. NSTORE Macro Call Format 


As examples of NSTORE use, consider the following 
operations. 

Example 1: 

SX2 MYARRAY 

NSTORE X2, PFC=CTRL 

These statements store the value predefined for CTRL 
in the primary function code field of MYARRAY. The 
primary function code field is Identified by the 
symbolic name RFC, and the address label MYARRAY is 
obtained through register X2. 

Example 2: 

NSTORE MYARRAY, PFC=CTRL 

This statement performs the same operation shown in 
example 1. 


Example 3: 

NSTORE MYARRAY, C0N0WT=7RTERMABC 

This statement stores the terminal name TERMABC in 
the owning console terminal name field of MYARRAY. 
The owning console terminal name field is identified 
by the predefined symbolic name CONOWT. 

If an NSTORE macro call is Issued with an error, the 
COMPASS assembler flags the error and provides an 
explanation during assembly of the macro. Appendix 
B contains a complete listing of the assembly error 
messages from NSTORE. 


COMPILER-LEVEL LANGUAGES 

Application programs coded in compiler-level 
languages such as FORTRAN use AIP statements that 
make relocatable subroutine calls. Such statements 
need not be declared as external routines. Entry 
point references are satisfied by the CYBER loader; 
the AIP routines are loaded from the local library 
NETIO or NETIOD, which must be declared in an LDSET 
or LIBRARY control statement. 

READ, WRITE, and CONNEC are not employed when NAM 
is used by a FORTRAN program for input and output 
between the program and terminals. Terminals serv¬ 
iced by an application program do not have logical 
unit numbers. 

ACCEPT and DISPLAY are not used when NAM is used by 
a COBOL program for input and output between the 
program and terminals. You can use these verbs in 
COBOL programs that use other network application 
programs, such as the CDC-written Transaction 
Facility (TAF), for network access. 

Packing and unpacking supervisory message blocks in 
a compiler-level program is easily accomplished 
using the interfacing utilities NFETCH and NSTORE. 
These field access utilities reside in local library 
NETIO or NETIOD. 

Programs written using compiler-level languages can 
also use the AIP routines indirectly through the 
utility package called the Queued Terminal Record 
Manager (QTRM). QTRM is described at the end of 
this subsection and the use of QTRM is completely 
defined in section 8. The subroutines comprising 
QTRM reside in local library NETIO or NETIOD. 


Application Interface Program Subroutine 
Call Formats 

Only one form of the AIP subroutine call is possible 
in compiler-level language programs. This form is: 

subroutine-name (parameters) 

The syntax of this form is discussed in section 5. 
A summary of all the calls available appears in 
appendix D. The FORTRAN form of the subroutine 
call format is the format used throughout this 
manual when discussing the AIP routines. 


Field Access Utilities 

Two additional relocatable subroutines, NFETCH and 
NSTORE, are provided to make message field defini¬ 
tion and access easier. Use of these routines and 
their related predefined symbolic names will 
simplify application program conversion under future 
versions of the network software. Because each call 
to one of these routines causes a table scan, use 
of the routines increases program execution time. 
This Increase can be minimized by setting up all 
constants processed by calls to the routines with a 
single set of calls at the beginning of the program. 
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NFETCH Function 


Example 2: 


A call to the NFETCH function subprogram returns an 
Integer value for the contents of a specific field 
within an array of one or more words that comprise 
all or part of a supervisory message block. NFETCH 
can be used anywhere In a program expression that 
an operand can be used; figure 4-3 defines the 
format for NFETCH as It Is used In an assignment 
statement. 


[ivalue= 

NFETCH(arrav,field) 

ivalue= 

A return parameter; as input to the call, an 
optional integer variable to receive the value 
returned for the function. 

array 

An input parameter, specifying the symbolic 
address of the first word of the array from 
which the field value can be obtained. This 
parameter can be: 


The array name 


Zero 


If zero is declared, any predefined value for the 
indicated symbolic name is returned. 

field 

An input parameter, specifying the predefined 
symbolic name of the field for which a value 
should be fetched from the array. The possible 
contents of field are listed in table 4-1. This 
parameter must be left-justified with zero fill. 


Figure 4-3. NFETCH Integer Function 
FORTRAN Call Format 


The size of the field involved in the NFETCH call 
determines the format of the content value returned. 
The field is read as an octal value and the value 
returned Is rlght-justlfled as either an Integer or 
a display code character string. 

If either the field or array parameter is omitted 
from the function statement, the application program 
is aborted and a dayfile message Is issued. (See 
appendix B.) 

As examples of NFETCH uses, consider the following 
operations. 

Example 1: 

The FORTRAN 5 statement: 

M"NFETCH(ARRAY,L"EB") 

makes M equivalent to the value of the error bit. 
The error bit is identified by the predefined sym¬ 
bolic name EB, left-justified with zero fill in the 
call. 


The FORTRAN 5 statement: 

M=NFETCH(0,L"CON") 

makes M the Integer value 143g, equivalent to the 
predefined value for the primary function code field 
in all connection-request supervisory messages. The 
primary function code field is identified by the 
predefined symbolic name CON, left-justified with 
zero fill In the call. 


Example 3: 

The FORTRAN 5 statement: 

IF(NFETGH(ARRAY,L"EB").EQ.l) CALL ERROR 

causes a jump to ERROR If the value of the error 
bit (EB) within ARRAY Is 1. 


NSTORE Subroutine 

A call to the NSTORE subroutine sets the contents 
of a specific field within an array of one or more 
words that comprise all or part of a supervisory 
message block. Figure 4-4 gives the FORTRAN format 
of the NSTORE call statement. 


CALL NSTORE(array,field,value) 

array 

A return parameter; as input to the call, the 
symbolic address of the first word of the array 
into which the field value should be placed. 

This parameter is normally the array name. 

field 

An input parameter, specifying the predefined 
symbolic name of the field for which a value 
should be stored in the array. The possible 
contents of field are listed alphabetically in 
table 4-1. This parameter must be left- 
justified with zero fill. 

value 

An input parameter, specifying the value to be 
stored in the identified field within the array. 

This parameter can be; 


A right-justified integer value 


A right-justified, zero-filled Hollerith 
character string 


A left-justified, zero-filled symbolic name 
with a predefined value (see table 4-1). 


Figure 4-4. NSTORE Subroutine 
FORTRAN Call Format 
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Integer values stored by the NSTORE call are stored 
as Integers. Character strings are stored In dis¬ 
play code form and symbolic names are converted to 
octal equivalents of their predefined values when 
stored. Only one field can be specified in each 
call. A value can be stored in a field any time 
after the array is declared. 

If either the array, field, or value parameters are 
not declared or are nonexistent, the application 
program is aborted and a dayflle message is Issued. 
(See appendix B.) 

As examples of NSTORE use, consider the following 
operations. 

Example 1: 

The FORTRAN 5 statement: 

CALL NSTORE(ARRAY,L"PFC",L"CON") 

stores the predefined value for the primary function 
code of all connection-request supervisory messages 
in the primary function code field of ARRAY. The 
primary function code value is identified by the 
predefined symbolic name CON and the primary func¬ 
tion code field by the predefined symbolic name PFC; 
both names are left-justified with zero fill in the 
call. 


Example 2: 

The FORTRAN 5 statement: 

CALL NSTORE(ARRAY,L"CONOWT",R"TERMABC") 

stores the display coded terminal name TERMABC in 
the owning console terminal name field of ARRAY. 
The owning console terminal name field is identified 
by the predefined symbolic name CONOWT, left- 
justified with zero fill in the call. 


Example 3: 

The FORTRAN 5 statement: 

CALL NSTORE(ARRAY,L"RB",1) 

sets the response bit field in ARRAY to 1. The 
response bit field is identified by the predefined 
symbolic name RB, left-justified with zero fill in 
the call. 


Queued Terminal Record Manager Utilities 

You can set up a teleprocessing service by inter¬ 
facing an application program directly with AIP 
through the subroutine calls described in section 
5. This interface requires manipulation of many 
bit-oriented fields, as described in section 2, and 
multiple operations to perform a single function, 
as described in section 3. These protocol require¬ 
ments can be quite complex, dwarfing the portion of 
a program's code that actually performs a teleproc¬ 
essing service when the service Itself is very 
simple. 


A FORTRAN programmer can use AIP directly with only 
minor inconvenience when shifting and masking are 
required. The NFETCH and NSTORE routines permit a 
COBOL prograiraner to bypass most of the shifting and 
masking problems of direct AIP use, but some remain. 
Shifting and masking is extremely difficult for a 
COBOL programmer when NFETCH and NSTORE cannot be 
used because COBOL constrains field access to fields 
that are multiples of 6 bits. NFETCH, which is 
coded as a function and not as atsubroutine, is not 
directly callable from a COBOL program because COBOL 
does not support functions. To use NFETCH, a COBOL 
programmer must write a subroutine in another 
applications language. 

The Queued Terminal Record Manager (QTRM) utility 
package allows compiler language users to remain 
unaware of AIP protocol requirements. QTRM also 
allows users of COBOL 5.2 (and later versions) to 
create teleprocessing service programs using an 
interface that is oriented to fields defined in 
multiples of 6 bits. 

QTRM is an indirect Interface to the network; its 
use is functionally analogous to directly calling 
CYBER Record Manager. Using QTRM, an application 
programmer can send messages to and receive messages 
from a network of terminals as if the programmer 
were reading and writing records or files in mass 
storage. This parallelism is shown in figure 4-5. 

QTRM is used through calls to the following sub¬ 
routines : 

QTOPEN, which is called once to establish 
communication between the application program 
and the network. A call to QTOPEN is analogous 
to opening a mass storage file. 

QTLINK, which is calJed to initiate an 
appllcation-to-application connection. 

QTGET, which is called each time part or all of 
a message is required from the network. A call 
to QTGET is analogous to a single read operation 
on a mass storage file. 

QTPUT, which is called each time part or all of 
a message is Intended for the network. A call 
to QTPUT is analogous to a single write oper¬ 
ation on a mass storage file. 

QTENDT, which is called to disconnect a single 
terminal from communicating with the application 
program. 

QTCIDSE, which is called once to end communi¬ 
cation between the application program and the 
network. A call to QTCLOSE is analogous to 
closing a mass storage file. 

QTTIP, which is called to deliver a synchronous 
supervisory message to a specified connection. 

QTLEND, which is called to loan a device 
connection to another application program 
residing in the same host. 

QTSUP, which is called to create and/or deliver 
asynchronous supervisory messages. 

QTCMD, which is called to alter the way QTRM 
executes. 
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Figure 4-5. QTRM Interface Level Analogy 


Additional QTRM subroutines are available to aid in 
the debugging of new QTSM application programs. 
They are: 

QTDBG, which is called to turn on or off 
logging of network traffic in the debug log 
file. 

QTREL, which is called to route a Job to the 
input queue to process the debug log file. 

QTSETF, which is called to allow the debug log 
file to be flushed if the application program 
terminated abnormally. 

QTtOG, which is called to write messages to the 
debug log file. 

QTDMB, which is called to perform a binary dump 
of the application program. 

The following QTRM subroutines aid in gathering 
statistical data for the application program: 

QTSTC, which is called to turn on or off AIP 
statistics gathering in the AIP statistics file. 

QTLGS, which is called to write the application 
programs own statistical data . to the , AIP 
statistics file. 


Operation of these procedures Is monitored and 
controlled through a network information table, 
analogous to a file information table. The network 
information table contains 10 central memory words 
of information about each device the application 
program can potentially service, and 10 words of 
global Information about the state of the appli¬ 
cation program's communication with the network. 

Application programs using-QTRM can use only those 
features of AIP that are provided through the QTRM 
procedure calls. Such application programs should 
not also contain calls to AIP routines other than 
NFETCH and NSTORE. QTRM performs the following 
functions: 

Assigns all active device connections to a 
single connection list and polls that list for 
input on behalf of the application program 

Performs all asynchronous supervisory message 
exchanges required during application program 
execution 

Provides the final logical line zero byte -term¬ 
inator in downline blocks containing display 
code characters 


60499500 T 


4-15 














QTRM is a simplified alternative to AIP and there¬ 
fore does not support all of the AIP features, 
QTRM does not support the following features: 

Parallel mode code execution, as provided 
through NETSETP and NETCHEK calls 

Fragmented buffer input and output, as provided 
through NETGETF, NETPUTF, and NETGTFL calls 

Application program connections with passive 
(batch) devices 

Multiple application connection lists 

Section 8 contains a complete description of the 
QTRM procedure calls and a sample program illus¬ 
trating QTRM use by a COBOL programmer. QTRM 
procedures are not discussed elsewhere because QTRM 
use precludes direct use of the AIP routines docu¬ 
mented by tbe remainder of this manual. 


INTERNAL INTERFACES 

The information in the remainder of this section is 
not needed to create a Network Access Method appli¬ 
cation program. This Information is provided as 
background for application programmers using the 
parallel mode processing feature of NAM, programmers 
with a need for understanding communication among 
the components of the network software, and pro¬ 
grammers needing to interpret a load map. 


APPLICATION INTERFACE PROGRAM 
AND NETWORK INTERFACE PROGRAM 
COMMUNICATION 

One copy of the Network Interface Program resides 
at a control point and communicates with separate 
copies of the Application Interface Program at each 
control point containing an application program. 
Communication between NIP and each copy of AIP 
occurs through system control point calls initiated 
by AIP. The mechanism for this communication is a 
fixed-length buffer of status bits, pointers, and 
data that is called a worklist. 


Worklist Processing 

When an application program requests connection 
with the network, its copy of AIP establishes a 
long-term connection with NIP. The long-term con¬ 
nection exists until the program requests discon¬ 
nection from the network, or until NIP is informed 
of the program's failure or termination by the 
operating system. While the long-term connection 
exists, an additional short-term connection occurs 
whenever AIP initiates a transfer of workllsts be¬ 
tween Itself and NIP. The short-term connection 
exists until NIP Issues a system control point call 
to end it. 

The requests made by an application program to AIP 
are either satisfied by AIP directly or collected 
into the worklist contained within the AIP portion 


of the application program's field length. AIP 
places entries in this worklist until one of the 
following occurs, . then initiates the short-term 
connection: 

NETON or NETOFF is called by the application 
program. (See section 5.) 

The worklist is full. 

Another entry cannot be made without causing 
the worklist to overflow. 

The application program calls a routine (NETGET, 
NETGETL, NETGETF, or NETGTFL) that obtains in¬ 
put from the network's data structures, other 
than AIP queues. (See section 5.) 

NETCHEK is called. 

The application program Issues a nonforced 
NETWAIT call to make itself available for roll¬ 
out or any input, and no supervisory messages 
or data are queued for it. (See section 5.) 

The application program issues a forced NETWAIT 
call. 

The application program calls NETPUTF, unless 
the total message text involved in the call is 
small enough to fit in the worklist. 

This worklist is used to queue outgoing supervisory 
or data messages, and to request a supervisory or 
incoming (upline) data message. A second buffer 
acts as a queue for Incoming supervisory messages. 
When AIP laltiates the short-term connection, it 
checks to see whether its supervisory message buffer 
is full; if not, AIP appends a request for supervi¬ 
sory message input to the end of the worklist and 
passes the worklist to NIP. The period during 
worklist processing is the only time when NIP can 
read from or write into the field length of AIP, 
and then only when AIP initiates the action. 

NIP processes the transferred worklist until all of 
the entries are satisfied, then ends the short-term 
connection. Worklist processing is suspended when: 

The operating system rolls out the application 
program. 

NIP causes the application program to be rolled 
out in response to the request of the program. 
(See NETWAIT call, section 5.) 

A worklist entry cannot be processed without 
obtaining additional central memory, which is 
not available. 

Even if ■ there are downline messages queued, no 
worklist transfer occurs in these instances: 

The application program calls a routine (NETGET, 
NETGETF, NETGETL, or NETGTFL) to obtain asyn¬ 
chronous supervisory messages and AIP transfers 
any queued messages to the application. 

The application program issues a NETWAIT call 
with a flag value of 0 and there are supervisory 
messages or data available for the application. 
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Generally, an application program does not depend 
on the status of worklist processing between its 
corresponding AIP copy and NIP. Most programs can 
adequately function when concerned only with text 
area buffers and calls to AIP. However, the Net¬ 
work Access Method does provide a mechanism that 
allows an application program to monitor worklist 
processing and execute code dependent on that proc¬ 
essing. This mechanism is called parallel mode 
operation. 


Parallel Mode Operation 

When an application program Issues the call that 
initiates the long-term connection, it identifies a 
supervisory status word that is used by AIP as a 
buffer for several flags. Among the supervisory 
status word flags are worklist processing bits used 
during parallel mode operations. 

When an application program is not processing in 
parallel mode (the normal, default condition), its 
copy of AIP Initiates the short-term connection 
with a system control point call specifying that 
recall is in effect. In this case, the program's 
copy of AIP does not regain control of the central 
processor until all worklist entries are processed 
by NIP and the short-term connection is ended. 
Because the application program cannot regain the 
central processor until its copy of AIP has regained 
the central processor, the program cannot perform 
any processing in the interim. 

Parallel mode operation is usually beneficial only 
when used on a dual CPU system, because NIP ordi¬ 
narily has a higher priority than any application 
program and gains control of the central processor 
after a call is made to it. NIP retains control 
until it completes processing of the worklist 
request. 

Processing in parallel mode is analagous to making 
operating system calls without recall. An applica¬ 
tion program enters parallel mode by issuing a call 
to the AIP routine NETSETP. While in parallel mode, 
anytime AIP initiates the short-term connection, it 
does so without specifying recall. The application 
program's copy of AIP reacquires control of a cen¬ 
tral processor as soon as the operating system's 
scheduling algorithm permits, and AIP returns con¬ 
trol to the calling point of the application program 
proper. As long as the short-term connection 
exists, the application program can continue proc¬ 
essing with the sole restriction that it cannot 
issue calls to any AIP routines other than NETCHEK 
or NETOFF. 

Calls to NETCHEK cause AIP to indicate the current 
status of worklist processing using a bit in the 
supervisory status word. After each NETCHEK call, 
the application program must check the supervisory 
status word. As soon- as the bit indicating com¬ 
pletion of worklist processing is set, the program 
is free to issue any AIP call. Parallel mode proc¬ 
essing is ended by a second call to the AIP routine 
NETSETP. 


The worklist processing completion bit serves 
several purposes in parallel mode operation. Calls 
to NETCHEK cause this bit to be set when processing 
of the previous request to AIP has been completed, 
even when that request did not cause a worklist 
entry or transfer. When a call to NETCHEK results 
in the completion bit being set, the application 
program can: 

Safely reuse any header area and text area used 
in its last AIP call 

Assume that any worklist transfer involved in 
the previous AIP function request resulted in 
the updating of the other bits in the super¬ 
visory status word 

When a call to NETCHEK does not result in the 
completion bit being set, the application program 
should issue additional NETCHEK calls before exe¬ 
cuting any code dependent on either condition. 

Calls to NETOFF end parallel, mode operation by end¬ 
ing both the long-term and short-term connections 
simultaneously. NIP processes a worklist containing 
a NETOFF call as if the worklist were transferred 
while the application program was not processing in 
parallel mode. Calls to NETCHEK are not necessary 
to test completion of a NETOFF call. 


OTHER SOFTWARE COMMUNICATION 

A complete compiler or assembler listing for an 
application program contains symbols and entry 
points not discussed in this manual. These symbols 
and entry points are used internally for interfacing 
between NIP, AIP, and the operating system. Table 
4-2 lists the names of Internal procedure calls with 
an outline of the function of each routine; these 
calls should not be used directly by the application 
program. In general, procedure names beginning with 
the three characters NP$ are reserved for use by AIP 
and should not be used by application programs. 
Table 4-3 lists the tables and common blocks in¬ 
volved in the processing of an application program's 
AIP statements. 


The Communications Supervisor, Network Supervisor, 
and Network Validation Facility Interface with NAM 
via the AIP procedure calls described in section 5. 
These Interfaces use special supervisory messages 
not described in section 3. These special super¬ 
visory messages cannot be used in another NAM 
application program. 

NAM interfaces with the network processing unit 
software through the Peripheral Interface Program, 
which uses an Internal block protocol not described 
in section 2. These blocks are compiled or inter¬ 
preted by NIP. 
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TABLE 4-2. AIP INTERNAL PROCEDURES 


Name 

Function 

NP$CLK 

Used only when AIP is run with either the debugging or statistics option on; gets system clock 
time. 

NP$DATE 

Used only when AIP Is run with either the debugging or statistics option on; gets current date. 

NP$DBG 

Used only when AIP is run with the debugging option on; makes entries in the debug log file 
(application program local file ZZZZZDN). These entries show results of calls to other AIP 
routines by the program. (See section 6.) 

NP$DMB 

Dumps field length to the application program local file ZZZZDMB. 

NP$ERR 

Issues error messages to the application program's dayfile. 

NP$GET 

Creates NETGET, NETGETL, NETGETF, or NETGTFL worklist entry to send to NIP. 

NPSGSM 

Refills AIP's supervisory message buffer. (See Worklist Processing.) 

NP$MSG 

Issues dayfile message to NIP's dayfile. 

NP$0N 

Processes NETON call response from NIP. 

NP$OSIF 

Issues system control point (SSC) RA+1 call. 

NP$PUT 

Creates NETPUT worklist entry to send to NIP. 

NP$PUTF 

Creates NETPUTF worklist entry to send to NIP. 

NP$RCL 

Allows AIP to go into recall. 

NP$READ 

Used only when AIP is run with the debugging option on; reads job record for NETREL call. 

NP$RESP 

Processes worklist responses from NIP. 

NP$ROOT 

Used only when AIP is run with the debugging option on; routes job to input queue for NETREL call. 

NP$RT1M 

Used only when AIP is run with the debugging option on; gets real time since deadstart. 

NP$RWD 

Used only when AIP is run with the debugging option on; rewinds a file. 

NP$SEND 

Called when a worklist must be transferred to NIP. 

NP$SLOF 

Used only when AIP is run with the debugging option on; executes SETLOF macro for NETSETF call. 

(See section 6.) 

NP$SN 

Used only when AIP is run with the statistics option on; accumulates statistical data. 

NP$SPRT 

Used only when AIP is run with the statistics option on; makes entries in the debug log file 
(application program local file ZZZZZSN). (See section 6.) 

NP$STM 

Allows COMPASS users access to common symbol definitions. 

NP$TIM 

Used only when AIP is run with the statistics option on; gets CPU time. 

NP$UCV 

Used to update AIP control variables. 

NP$USI 

Used to update the S and I bits in the supervisory status word. (See section 5.) 

NP$WRTO 

Used only when AIP is run with the debugging option on; writes one word in the debug log 
file (application program local file ZZZZZDN). (See section 6.) 

NP$WRTR 

Used only when AIP is run with either the debugging or statistics option on; writes end-of-record 
to the debug log file or statistics file. (See section 6.) 

NT$WRTW 

Used only when AIP is run with either the debugging or statistics option on; writes entry to the 
debug log file or statistics file. (See section 6.) 

NP$XCDD 

Used only when AIP is run with the statistics option on; converts numbers to decimal form in 
display code. 

NP$XFER 

Transfers a worklist to NIP. 
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TABLE 4-3. AIP INTERNAL TABLES AND BLOCKS 


Name 

Function 

NP$DB 

Used only when AIP Is run with the debugging option on; contains calling parameters for 
debugging routine NP$DBG. 

NP$GETS 

Controls variables used to process NETGET, NETGETL, NETGETF, and NETGTFL calls. 

NP$L0F 

Used only when AIP is run with the debugging option on; parameter block for SETLOF 
macro. (See section 6.) 

NP$MODE 

Used to keep track of the state the application is in. 

NP$NWL 

Workllst for the application program. 

NP$NWNC 

Used only when AIP is run with the debugging option on; aids in character conversion. 

NP$ONAM 

NETON entry for the debug log file. 

NP$PUTS 

Controls variables used to process PUT calls. 

NP$SMB 

AIP supervisory message buffer for the application program. This block is Included in 
the last lOOg words of NP$NWL. 

NP$STAT 

Used only when AIP is run with the debugging option on; contains statistics gathered by 

NIP. (See section 6.) 

NP$TAA 

Used to reference the text area array (TAA) in fragmented NETGETF and NETPUTF or NETGTFL 
calls. 

NP$ZHDR 

Header entry for the debug log file (application program local file ZZZZZDN). 
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APPLICATION INTERFACE PROGRAM CALL STATEMENTS 


5 


This section describes the Application Interface 
Program (AIP) statements used by a network appli¬ 
cation program to access the network, control 
network processing, and transmit and receive the 
messages described in sections 2 and 3. 


SYNTAX 

Application Interface Program statements are used 
in COMPASS programs, or in programs written in 
high-level languages such as FORTRAN. In most 
high-level languages, only positional parameters 
can be used; AIP statements conform to this syntac¬ 
tical requirement and, therefore, do not permit the 
use of keywords. The interpretation attached to a 
given parameter is determined solely by its location 
within the string of parameters of each AIP state¬ 
ment. All input parameters must be supplied; there 
are no defaults. 

The FORTRAN positional form is used throughout this 
section to present AIP statements. Coding the 
statements when they are used in other languages 
requires few modifications. For example, in the 
form of a COMPASS macro call, a sample NETGETL 
statement has the form: 

[label] NETGETL aIn, ha, ta, tlmax 

This converts to the FORTRAN subroutine syntax, 
which is: 

CALL NETGETL (aln, ha, ta, tlmax) 

Use of LIST and label are discussed in section 4 
where COMPASS Interface requirements are given. 

The FORTRAN subroutine syntax, in turn, converts to 
the following COBOL syntax for the same statement: 

ENTER FORTRAN-X NETGETL 

USING aln, ha, ta, tlmax 

The mnemonic variables identifying each parameter 
are defined in the statement descriptions, along 
with any coding constraints imposed on them. Commas 
delimit parameters in all languages; the signifi¬ 
cance of blanks depends on the language used. 
Unless otherwise specified, all values supplied for 
parameters should be decimal Integers. 

General definitions of terms appearing in parameter 
descriptions are given in the glossary. More 
detailed definitions and parameter constraints that 
depend on the programming language used are given 
in section 4 under the heading of Language Inter¬ 
faces. Program structural considerations that 
depend on command use are described in section 6 
under the headings of Commands and Dependencies. 


NETWORK ACCESS STATEMENTS 

An application program uses two AIP statements to 
begin and end access to the network's resources. 
The NETON statement must be used before the program 
can use any other AIP statement except NETREL, 
NSTORE, NFETCH, NETSETF, NETCHEK, NETSETP, or 
NETOFF. The NETOFF statement must be used after 
all AIP functions are completed to cause the AIP 
portion of the application program to perform vital 
housekeeping tasks; these tasks are associated with 
debug log file, statistical file, and login proc¬ 
essing by the network software. 

CONNECTING TO NETWORK (NETON) 

The NETON statement (figure 5-1) performs the 
following functions: 

Identifies the application program to the net¬ 
work so that the Network Validation Facility 
(NVF) can validate the right of the program to 
access the network's resources 

Causes AIP to establish communication with NIP 

Identifies a word to be used for communication 
from AIP to the program, outside of the super¬ 
visory message mechanism (figure 5-2) 

Informs the network software of limitations on 
the number of logical connections the program 
can handle 

Causes AIP to begin debug log file and statis¬ 
tical file compilation, if AIP contains code 
permitting this (See section 6.) 

An application program must successfully complete a 
NETON call before it can use any AIP statement 
other than NETOFF, NETCHEK, NETREL, NETSETF, or 
NETSETP. If another AIP statement is used before a 
NETON call is successfully completed, AIP aborts 
the job and issues a message to the job's dayflle. 
The incorrectly placed call has no other effect. 

An application program's NETON statement is success¬ 
fully validated by the Network Validation Facility 
when the program name contained in the NETON call 
appears in the system common deck COMTNAP. If the 
program is defined as a privileged application in 
the local configuration file, it must meet the 
requirements for such to be successfully validated. 
(See section 6.) 

If validation is not successful, the application 
program is aborted. If validation is successful, 
the program has access to the network as long as a 
NETOFF statement is not issued and communication 
with NIP continues. 
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CALL NETON {aname,nsup,status,minacn,maxacn) 

aname An input parameter, specifying in 6-bit display code the name of the application program, as 
it is identified for log in and in the system OPL common deck COHTNAP. This can be one to 
seven alphabetic and numeric characters, but the first must be alphabetic. This.parameter 
must be left-justified, with blank fill. It is advisable to avoid names beginning with the 
letters NET to make loader map interpretation easier. The following application program 
names are reserved for internal networks use: 


ABORT 

INITHDI 

NETLS 

PFU 

RBF 

ALL 

ITF 

NETOS 

PLATO 

RMF 

BYE 

LOGIN 

NETTU 

PSU 

SCF 

CS 

LOGOUT 

NIP 

PTF 

TAF 

DOP 

HCS 

NLTERH 

PTFI 

TCF 

FTF 

MHF 

NOF 

PTFS 

TVF 

FTFS 

MLTF 

NS 

OTF. 

VEIAF 

HELLO 

NAM 

NUL 

OTFI 


lAF 

NETFS 

NVF 

QTFS 



Use of some of these names causes the program job to be aborted; use of the remainder can 
cause unpredictable errors. 

nsup A return parameter; as input to the call, nsup is the symbolic address of the supervisory 

status word for communication from AIP to the application program. This word has the format 

shown in figure 5-2. The upper bit of this word is relevant during parallel mode processing 

only; this bit reports the status of worklist processing and is updated after each AIP call 
except NETSETP. Bits 56 and 55 are set when indicated in the figure to report the status of 
the data message and supervisory message queuing performed by AIP. These bits are valid 
after any AIP call except NETDBG, NETL06, NETREL, NETSETF, NETSETP, or NETSTC. This word 
need not contain zeros at the time of the NETON call and should not be changed at any time by 
the application program. 

status A return parameter; as input to the call, status is the symbolic address of the NETON call 
status word. On return from the call (or when worklist processing is complete if the call 
was made in parallel mode), the content of this word indicates the network software's 
disposition of the application program's NETON attempt. The values of status can be: 

0 NETON was successful. 

1 NETON was unsuccessful because NIP was not at a control point. 

2 NETON was rejected because the maximum number of allowed applications has already 

netted on. 

3 NETON was rejected because the application program has a status of disabled in the 
Network Validation Facility tables. The program must be rerun after its entry in the 
local configuration file has been changed or after the host operator has enabled it. 

minacn An input parameter, specifying the smallest application connection number the application 

program can process; 0 < minacn < maxacn < 4095. The network software assigns acn values to 
connections, beginning with the number specified for minacn. (See section 2.) 

maxacn An input parameter, specifying the largest applicaton connection number the application 

program can process; 0 < minacn < maxacn < 4095. The network software does not attempt to 
complete any more connections to the program after all connections from minacn through maxacn 
(inclusive) are in use. 


Figure 5-1. NETON Statement FORTRAN Call Format 


If the program loses communication with NIP, it is 
aborted by the operating system unless it is a 
system control point job. System control point 
jobs are not aborted. The program can reprieve 
itself from such an abort by using the NOS REPRIEVE 


macro. The program should examine the last error 
flag that was set for the job (by using the NOS 
GETJCR macro) to determine the cause of the pro¬ 
gram's failure. 


5-2 
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AIP request and worklist processing compLetion bit. This bit is relevant only in parallel mode. 
When any AIP routine other than NETSETP is entered and the AIP function is not completed, the bit 
is set to zero. If the AIP function is completed, the bit is set to one, if a worklist transfer 
was required. If the bit is zero, the program cannot call any AIP routines except NETCHEK or 
NETOFF nor can it use the header area and text area of the last AIP call until the bit is set to 
one. The bit is set to one by NETCHEK when the last AIP function is completed. 

Reserved for CDC use. 

NAM available bit. This bit is set to one upon return from a NETON call if NAM is available, and 
zero if NAM is not available. The bit is also set to zero by AIP when AIP is informed by the 
operating system that NAM is no longer available. 

Input-in-queue bit. This bit is set to one if NIP has either data messages or synchronous 
supervisory messages queued for the application. The bit is valid after any AIP call except a 
call to NETOBG, NETLOG, NETDMB, NETLGS, NETREL, NETSETF, NETSETP, or NETSTC. This bit is set to 
zero when no data messages or synchronous supervisory messages remain queued for the program. 

Supervisory message in queue bit. This bit is set to one if asynchronous supervisory messages 
are queued on application connection number 0 for this program. This bit is valid after any AIP 
call except a call to NETOBG, NETDMB, NETLGS, NETLOG, NETREL, NETSETF, NETSETP, or NETSTC. The s 
bit is set to zero when no asynchronous supervisory messages remain queued for the program. 

Data-deliverable bit. This bit is set to one if data messages are deliverable on at least one of 
the connection lists of the application program and the application program issues a NETGETL or a 
NETGTFL call. 

Reserved for CDC. Reserved fields contain zero. 

A count of the number of supervisory messages and network data blocks on the debug log file when 
library NETIOD is used. A NETON call Cor a NETREL call with a nonzero Ifn parameter value) 
resets the count to zero (described in section 6). 


Figure 5-2. Supervisory Status Word Format 


If the program failed because NAM failed. It should 
issue a NETOFF call and successfully complete 
another NETON call before Issuing any further calls 
to the AIP routines. The NETOFF call, used in this 
case, causes AIP to perform Internal housekeeping 
functions and finish information transfer to the 
debug log and statistical files; the second NETON 
causes AIP to reinitialize Internal tables and 
reestablish communication with NIP, If a new copy 
of NIP becomes available prior to the NETOFF call, 
the second NETON call causes the NETOFF statement 
to be ignored and program processing can be resumed 
after new logical connections have been established. 
Alternating NETON and NETOFF statement sequences in 
parallel mode have unpredictable results. 


The network software tracks an application program 
and Issues dayflle messages concerning the program 
on the basis of the aname parameter used in the 
program's NETON call. The operating system, how¬ 
ever, is unaware of this name and issues dayflle 
messages on the basis of the job name assigned to 
the program according to the contents of the job's 
command portion. So that all dayflle messages 
concerning the same program can be identified, you 
should take the steps described in section 6. 


called RMV2, is Identified by that name in COMTNAP 
and in the local configuration file as a non- 
privileged application. EMV2 can process up to 
three logical connections but requires connections 
to be numbered beginning with 2. RMV2 uses the 
Integer word NSUP as a supervisory status word for 
communication from AIP and tests for successful 
completion of the NETON call through the Integer 
word NSTATUS. 


COMMON NSUP,HA(2),TA(200,2) 


NAME=4HRMV2 

NSTATUS=0 

HINACN=2 

MAXACN=4 

CALL NETON(NAME,NSUP,NSTATUS,MINACN,MAXACN) 
IF (NSTATUS.NE.O) GO TO 999 


999 PRINT 998, NSTATUS 
998 FORMAT('NSTATUS IS',112) 
STOP 


Figure 5-3 contains a portion of a FORTRAN program 
that correctly performs a NETON call. The program. 


Figure 5-3. NETON Statement FORTRAN Example 
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DISCONNECTING FROM NETWORK (NETOFF) 

The NETOFF statement (figure 5-4) performs the 
following functions: 

Breaks AIP communication with NIP 

Causes AIP to finish formatting and transferring 
information for the debug log file and statis¬ 
tical file, if these files are being compiled 

Clears AIP internal tables so that the program 
can issue another NETON call, if necessary 


CALL NETOFF 


Figure 5-4. NETOFF Statement FORTRAN 
Call Format 

The NETOFF statement is used after all processing 
of logical connection activities is finished and 
the program is prepared to end connection with the 
network. After the NETOFF call is completed, no 
AIP statement other than NETON, NETREL, NSTORE, 
NFETCH, NETDMB, and NETSETF can be used. The NETOFF 
call breaks any logical connection still existing 
between the application program and a device or 
another application and prevents the network soft¬ 
ware from attempting to establish any new connec¬ 
tion. After the NETOFF statement is processed, the 
application program continues to execute under 
control of the operating system. 

An application program should always issue a NETOFF 
call before terminating. Otherwise, the network 
software informs consoles or other application 
programs with which connections exist that the 
program has failed; passive device connections are 
disposed of by the network software as if the 
program had failed. Unless a NETOFF call is com¬ 
pleted or NETREL is called, the debug log file 
compiled during job execution cannot be correctly 
disposed of. Unless a NETOFF call is completed, 
the statistical file compiled during Job execution 
will not exist. 

The NETOFF statement can also be used in a reprieval 
situation. This use is described under Connecting 
to Network (NETON). 


NETWORK BLOCK INPUT/OUTPUT 
STATEMENTS 

Input and output on logical connections can be 
handled through unified or fragmented buffers. 
Input can be obtained from a connection either by 
its individual connection number, or according to 
its membership in a list of connections. AIP 
statements permit an application program four 
options for input or output from a specific con¬ 
nection and two options for input from a connection 
on a list. 

SPECIFIC CONNECTIONS 

The four options for specific connection input and 
output are as follows; 

Fetch input to a single, unified buffer (NETGET 
statement) 

Fetch input to an array of buffers (NETGETF 
statement) 

Send output from a single, unified buffer 
(NETPUT statement) 

Send output from an array of buffers (NETPUTF 
statement) 


Inputing to Single Buffer (NETGET) 

You can use NETGET to obtain an asynchronous super¬ 
visory message from application connection number 
0. You can also use NETGET to fetch synchronous 
supervisory messages and network data blocks from 
application connection numbers other than 0. 
Synchronous supervisory messages and network data 
blocks are never queued on logical connection 0. 

Each NETGET call transfers one data or supervisory 
message block from the NIP queue for the connection 
specified in the call. The NETGET call places the 
block header in the application program's block 
header area and the network block in the application 
program's text area. The NETGET statement has the 
format shown in figure 5-5. 


CALL NETGET(acn,ha,ta,tLmax) 


acn An input parameter, specifying the application connection number of the Logical connection from 
which a block is requested. This parameter can have the values: 

0 Transfer one asynchronous supervisory message. 

minacn ^ Transfer one network data block or synchronous supervisory message from the 

acn ^ maxacn logical connection with the indicated acn. 

ha A return parameter; as input to the call, ha is the symbolic address of the application 

program's header area. The header area always contains an updated application block header 
after return from the call. 


Figure 5-5. NETGET Statement FORTRAN Call Format (Sheet 1 of 2) 
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ta A return parameter; as input to the call, the symbolic address of the first word of the buffer 

■array constituting the text area for the application program. On return from the call, the 
text area contains the requested block if a block was delivered to the application. The text 
area identified by ta should be at least tlmax words long. 

tlmax An input parameter, specifying the maximum length in central memory words of a block the 

application program can accept. The value declared for tlmax should be less than or equal to 
the length of the text area identified in the same call; if tlmax is greater than the length of 
the text area, the block transfer resulting from the NETGET call might overwrite a portion of 
the program. The maximum value needed for tlmax is a function of the block size used by the 
connection for input to the program and of the application character type the program has 
specified for input from the connection. The following ranges are valid: 

act=1 1 tlmax _< 410 for 60-bit (one per word) transparent characters 

act=2 1 ^ tlmax ^ 273 for 8-bit (7.5 per word) ASCII characters 

act=3 1 £ tlmax £ 410 for 8-bit (5 per word) ASCII characters 

act=4 1 £ tlmax £ 205 for 6-bit (10 per word) display code characters 

A tlmax value of 0 can be legally declared but results in an input-block-undeliverable 
condition; that is, an application block header is returned with a set ibu field, even when an 
empty block of application block type 2 is queued (a block with a tic value of 0). 


Figure 5-5. NETGET Statement FORTRAN Call Format (Sheet 2 of 2) 


If no network block is available from the indicated 
connection, AIP returns a null block; that is, AIP 
places a header word with an application block type 
of zero in the header area, and leaves the text 
area unchanged from what it contained after any 
previous transfer. 

The application program indicates the size of its 
buffer in each NETGET call. If a network block 
larger than this size is queued from the specified 
connection, the network block remains queued. AIP 
copies the header word of the block into the appli¬ 
cation program's block header area, sets the ibu 
bit of the header to one to indicate the condition, 
and places the actual length of the queued block in 
the tic field of the header. The application pro¬ 
gram's text area is unchanged from what it contained 
after any previous transfer. To obtain the still- 
queued network block, the program must issue another 
ffiTGET call indicating a buffer size sufficient to 
accommodate the queued block, or issue a DC/TRU/R 
asynchronous supervisory message to have the data 
truncated. (See section 3.) If block truncation 
is in effect at the time of the NETGET call, then 
the block is delivered with the tru bit set in the 
header. 

If the application program's text area is larger 
than the block transferred by the NETGET call, the 
portion of the text area after the last word used 
for the block remains unchanged from what it con¬ 
tained after any previous transfer. If the trans¬ 
ferred block does not completely fill the last word 
used for it, all character positions in the last 
word used are altered by the transfer. Only the 
leftmost character positions of the last word 
included in the block header word tic field value 
contain meaningful data. 

Figure 5-6 contains two examples of NETGET use. 
The first occurrence is in fetching asynchronous 
connection-request supervisory messages. Fetching 


INTEGER TA(26),HA,TLMAX,OVTLHAX 
DATA HA/0/,TA/20*0/,TLnAX/10/ 

• 

NACN=0 

1 CALL NETGET(NACN,HA,TA,TU»IAX) 

IF((NSUP.AND.0"02000000000000000000").EQ.0) 
1G0 TO 2 

• 

o 

GO TO 1 

2 CONTINUE 

• 

• 

NACN=TERH(IACN) 

3 CALL NETGET(NACN,HA,TA,TLnAX) 
IF(NFETCH(HA,L"ABHABT").EQ.O) GO TO 4 
IF(NFETCH(HA,L"ABHIBU").EQ.1) GO TO 5 

6 CONTINUE 

• 

• 

GO TO 3 

5 OVTL«AX=NFETCH(HA,L"ABHTLC")/7.5 
ATEMP=NFETCH(HA,L"ABHTLC")/7.5 
IF(ATEMP.NE.0VTLMAX)0VTLHAX=0VTLMAX + 1 
IF(0VTLMAX.GT.26) GO TO 9 
CALL NETGET(NACN,HA,TA,OVTLMAX) 

GO TO 6 

4 CONTINUE 

• 

9 STOP 


Figure 5-6. NETGET Statement FORTRAN 5 
Examples 
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continues until no asynchronous messages are 
reported via the supervisory status word (test of 
NSUP contents). The second appearance of NETGET Is 
in a loop polling for any messages queued on a 
device connection; the polling loop continues until 
a NETGET call returns a null block. The block 
header word HA is tested after each call to detect 
the null block, which has an application block type 
(ABHABT) of zero. 

The value chosen for TLMAX in this example is 
adequate for both a connection-request supervisory 
message of thirteen 60-bit characters and for a 
logical line of 72 teletypewriter characters, or 
for a minimum-sized network block of 100 characters 
from a longer logical line, with an application 
character type of 2 used for input. The text area 
array TA has a dimension of twice TLMAX words, in 
case the test of ABHIBO fails and a block larger 
than anticipated must be transferred (third NETGET 
call). 


Inputing to Fragmented Buffer Array (NETGETF) 

You can use NETGETF to obtain an asynchronous 
supervisory message from application connection 
number 0. You can also use NETGETF to fetch 
synchronous supervisory messages and network data 
blocks from application connection numbers other 
than 0. Synchronous supervisory messages and 
network data blocks are never queued on logical 
connection 0. 

Each NETGETF call transfers one data or supervisory 
message block from the NIP queue for the connection 
specified in the call. The NETGET call places the 
block header in the application program's block 
header area. It divides the block into fragments 
of whole central memory words and places each 
fragment in a separately addressed application 
program text area. The NETGETF statement has the 
format shown in figure 5-7. 


The text areas used are defined for AIP by the text 
area address array identified in the NETGETF call. 
This text area address array has the format given 
in figure 5-8. 

The application program indicates the total size of 
its text area buffers in each NETGETF call through 
fields in the text area address array. If a block 
larger than this total size is queued from the 
specified connection, the block remains queued. 
AIP copies the header word of the block into the 
application program's header area, sets the ibu bit 
of the header to one to indicate the condition, and 
places the actual length of the queued block in the 
tic field of the header. The application program's 
text areas are unchanged from what they contained 
after any previous transfer. To obtain the still- 
queued message block, the program must issue another 
NETGETF call, indicating a total text area size 
sufficient to accommodate the queued block, or it 
must issue a DC/TRU/R supervisory message (see 
section 3). 


If the total size of the application program's text 
areas is larger than the block transferred by the 
NETGETF call, the portions of the text areas after 
the last word used for the block remain unchanged 
from what they contained after any previous trans¬ 
fer. If the transferred block does not completely 
fill the last word used for it, all character 
positions in the last word used are altered by the 
transfer. Only the leftmost character positions of 
the last word included in the block header word tic 
field value contain meaningful data. 

If no message block is available from the indicated 
logical connection, AIP returns a null block; that 
is, a header word with an application block type of 
zero is placed in the header area, and the text 
areas remain unchanged from what they contained 
after any previous transfer. 


CALL NETGETF(acn,ha,na,taa) 


acn An input parameter, specifying the application connection number of the Logical connection 
from which a block is requested. This parameter can have the values: 

0 Transfer one asynchronous supervisory message. 

minacn ^ Transfer one network data block or synchronous supervisory message from the 

acn ^ maxacn Logical connection with the indicated acn. 

ha A return parameter; as input to the call, ha is the symbolic address of the application 

program's header area. The header area always contains an updated application block header 
after return from the call. 

na An input parameter, specifying the number of fragments the block should be divided into. The 

number used should be the same as the number of central memory word entries in the text area 
address array identified by the taa parameter; if na is greater than the Length of the text 
area address array, the block transfer resulting from the NETGETF call might overwrite a 
portion of the program. Parameter na can have values 0 < na £ 40. 

taa An input parameter, specifying the symbolic address of the first word of the one-dimensional 
array defining the application program's text areas. The array identified by taa has the 
format shown in figure 5-8. 


Figure 5-7. NETGETF Statement FORTRAN Call Format 
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unused 

size-i 

unused 

address^ 



unused 


unused 

addresspg 


addressj 


The symbolic address of the beginning of the array used in the NETGETF call. 

The length in central memory words of block fragment i. This field can contain the values 
^ i ®’^®i < 63. The sum of all na values for size^ defines the size in central memory 
words of tWe largest block the call can transfer; this sum is the equivalent of the tlmax 
parameter in the NETGET statement. The sum of all na values for size can be 0, but this 
results in an input-block-undeliverable condition; that is, an application block header is 
returned with a set ibu field, even when an empty block of application block type 2 is 
queued (a block with a tic value of 0). 

The relative numeric address of the first word of the application program text area to 
receive block fragment i. The text area addresses given in this field need not be for 
contiguous central memory areas. 


Figure 5-8. NETGETF Statement Text Area Address Array 


Figure 5-9 contains examples of NETGETF use. The 
program uses the first NETGETF call to fetch a 
block containing an entire screen of data, which 
AIP fragments Into 12 text areas containing one 
60-character physical line each. The application 
character type chosen for input from the logical 
connection is 4. The program continues to fetch 
full screen buffers of data until a null block is 
encountered by the test of ABHABT. The text areas 
used are 12 separately addressed 6-word arrays 
(LINEl through LINE12), which initially contain 
blanks (DATA statements). The text area address 
array (TAA), contains 12 corresponding words; each 
word contains the relative address of a text area, 
obtained with the LOCF function. Although the 
array TAA has a dimension of 24, only the first 12 
entries are expected to be used; therefore, a value 
of 12 is assigned to NA in its DATA statement. 
Only the first assignment statement constructing 
TAA is shown; because each text area will contain 
six words of ten 6-bit characters each, a size of 6 
is declared in each TAA entry. 

The second NETGETF call recovers a block not 
delivered by the original call because the block was 
larger than expected. This condition is detected 
by the test of ABHIBU, as returned by the first 
NETGETF call. The second call is issued with more 
of the text area address array specified, so that 
all 24 text areas potentially can be used. 


Outputing From Single Buffer (NETPUT) 

You can use NETPOT to send asynchronous supervisory 
messages to application connection number 0. You 
can also use NETPUT to send synchronous supervisory 
messages and network data blocks to application 
connection numbers other than 0. Synchronous 
supervisory messages and network data blocks are 
never sent on logical connection 0. 


DIMENSION LINE 1(6),...,LINE24(6) 

INTEGER HA,TAA(24),0VRFLNA,TERH(20) 

DATA NA/12/,HA/0/,LINEl/6*L""/,...,LINE24/6*L""/ 


TAA(1)=SHIFT(6,30).0R.L0CF(LINE1) 


NACN=TERH(IACN) 

1 CALL NETGETF(NACN,HA,NA,TAA) 
IF(NFETCH(HA,L"ABHABT") .EO.O) GO TO 2 
IF(NFETCH(HA,L"ABHIBU'*).E9.1) GO TO 5 

6 CONTINUE 

• 

• 

GO TO 1 

5 0VRFLNA=NFETCH(HA,L"ABHTLC")/60.0 
ATEHP=NFETCH(HA,L"ABHTLC")/60.0 
IF(ATEMP.NE.0VRFLNA)0VRFLNA=0VRFLNA + 1 
IF(0VRFLNA.GT.24) GO TO 9 
CALL NETGETF(NACN,HA,OVRFLNA,TAA) 

GO TO 6 

2 CONTINUE 

• 

9 STOP 


Figure 5-9. NETGETF Statement 
FORTRAN 5 Examples 


Each NETPUT call requests AIP to form a block from 
the information located in the application program's 
block header and text areas. The calling appli¬ 
cation program must construct a complete block 
header, as described in section 2. The text portion 
of the block can be either a network data block, as 
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described in section 2 , or a supervisory message 
block, as described in section 3. The block formed 
by AIP is sent to the logical connection specified 
in the block header. The NETPUT statement has the 
format shown in figure 5-10. 


CALL NETPUT(ha,ta) 

ha An input parameter, specifying the 

symbolic address of the application 
program's block header area. The block 
header area must contain a valid block 
header word. 

ta An input parameter, specifying the 

symbolic address of the application 
program's text area. The text area must 
contain a valid network data or super¬ 
visory message block, correctly described 
by the contents of the block header area. 


Figure 5-10. NETPUT Statement 
FORTRAN Call Format 

To reduce data transfer overhead, downline data is 
sometimes buffered by AIP within the application 
program's field length. Completion of a NETPUT 
call therefore does not necessarily mean that the 
downline data has been transferred to the network. 

When an application program is not operating in 
parallel mode, return from a NETPUT call is equiv¬ 
alent to completion of the call, and the application 
program can reuse the header area and text area 
specified in the call immediately. When an appli¬ 
cation program is operating in parallel mode, 
return from the call is not equivalent to completion 
of the call. Completion of the call must be deter¬ 
mined through the supervisory status word bits. If 
completion is not detected when these bits are 
checked, completion must be forced through calls to 
NETCHEK. The header area and text area cannot ' be 
reused safely until completion occurs. Otherwise, 
AIP might transfer information on the wrong connec¬ 
tion or data other than what the application 
Intended to transfer as part of the block. 

Actual transfer of downline data occurs any time 
the application program makes an AIP call that 
requires access to the network software's data 
structures. Any NETGET or NETGETF call causes 
downline transfers when the call is not made on 
connection number 0. Any NETWAIT call with a flag 
value of one causes downline transfers. A NETGETL 
or NETGTFL call causes downline transfers when the 
call is not made on list number 0. Other AIP calls 
do not necessarily cause Immediate downline trans¬ 
fers, and downline data buffered by AIP may remain 
untransferred if the application program is swapped 
out by the operating system. Downline data buf¬ 
fered by AIP might also remain untransferred if the 
application program schedules its own central 
processor usage with the COMPASS macro RECALL, 
Instead of using calls to NETWAIT. To force the 
transfer of downline data buffered in AIP, call 
NETCHEK. (See Workllst Processing in section 4.) 


Figure 5-11 contains an example of NETPUT use. The 
program has fetched an asynchronous supervisory 
message and determined that the message is a con¬ 
nection request from a console. The header area 
contains the connection-request block header. 
Because asynchronous supervisory messages use an 
application character type of one, the connection- 
accepted message being created in the example 
requires the first NSTORE call to place a 1 in the 
tic field. The response message is only one 
central memory word, viewed as a single character. 
The next four lines of code modify the first word 
of the connection-request message, contained in 
text area TA. First, the NSTORE call sets the 
response bit (RB). Next, the NSTORE call places a 
list number in the connection-accepted message, 
followed by an application character type of 4. 
Six-bit display code characters are to be used for 
input from this connection, an option that is legal 
for consoles because they use the interactive 
virtual terminal interface. Finally, the NETPUT 
call sends the completed message on application 
connection number 0. The incoming block header 
already contained this number, so the program did 
not need to supply it while constructing the out¬ 
going block header. 


• 

CALL NSTORECHA,L”ABHTLC",1) 

CALL NST0RE(TA(1),2LRB,1) 

CALL NSTORE(TAC1),L"C0NALN",TERH(1,8)) 
CALL NSTORECTA(1),L"C0NACT",4) 

CALL NETPUT(HA,TA) 

• 


Figure 5-11. NETPUT Statement 
FORTRAN 5 Example 


Outputing From Fragmented Buffer 
Array (NETPUTF) 

You can use NETPUTF to send asynchronous supervisory 
messages to application connection number 0. You 
can also use NETPUTF to send synchronous supervisory 
messages and network data blocks to application 
connection numbers other than 0. Synchronous 
supervisory messages and network data blocks are 
never sent on logical connection 0. 

Each NETPUTF call requests AIP to form a message 
block from the information located in the appli¬ 
cation program's block header and scattered text 
areas. The calling application program must con¬ 
struct a complete block header, as described in 
section 2. The text portion of the block can be 
either a network data block, as described in section 
2, or a supervisory message block, as described in 
section 3. The block formed by AIP is sent to the 
logical connection specified in the block header. 
The NETPUTF statement has the format shown in figure 
5-12. 


5-8 
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CALL NETPUTF(ha,na,taa) 


ha An input parameter, specifying the 
symbolic address of the application 
program's block header area. The block 
header area must contain a valid block 
header word. 

na An input parameter, specifying the number 
of fragments the block is divided into. 

The number used should be the same as the 
number of central memory word entries in 
the text area address array identified by 
the taa parameter; if na is greater than 
the length of the text area address array, 
the block transferred by the NETPUTF call 
might contain meaningless information 
appended to the last meaningful fragment. 
Parameter na can have the values 1 £ na £ 
40. 

taa An input parameter, specifying the 

symbolic address of the first word of the 
one-dimensional array defining the 
application program's text areas. The 
array identified by taa has the format 
shown in figure 5-13. 


Figure 5-12. NETPUTF Statement 
FORTRAN Call Format 


NAM assembles the text portion of the block trans¬ 
ferred by the call from separately addressed text 
areas scattered through the application program's 
field length. The addresses and sizes of these 
text areas are supplied to AIP through a text area 
address array specified in the NETPUTF call. (The 
text area address array is shown in figure 5-13.) 
The total size of all of the text areas identified 
in the text area array should be greater than or 


equal to the central memory word equivalent of the 
number of characters specified In the block header. 
If the block header declares the block to contain 
fewer central memory words than all the text areas 
contain, the portion of the text areas beyond the 
size declared in the block header will not be 
included in the transferred block. 

To reduce data transfer overhead, downline data Is 
sometimes buffered by AIP within the application 
program's field length. Completion of a NETPUTF 
call therefore does not necessarily mean that the 
downline data has been transferred to the network. 

When an application program is not operating in 
parallel mode, return from a NETPUTF call is 
equivalent to completion of the call, and the 
application program can reuse the header area and 
text areas specified in the call immediately. When 
an application program is operating in parallel 
mode, return from the call is not equivalent to 
completion of the call. Completion of the call 
must be determined through the supervisory status 
word bits. If completion is not detected when 
these bits are checked, completion must be forced 
through calls to NETCHEK. The header area and text 
areas cannot be reused safely until completion 
occurs. Otherwise, AIP might transfer information 
on the wrong connection or data other than what the 
application intended to transfer as part of the 
block. 

Actual transfer of downline data occurs any time 
the application program makes an AIP call that 
requires access to the network software's data 
structures. Any NETGET or NETGETF call causes 
downline transfers when the call is not made on 
connection number 0. Any NETWAIT call with a flag 
value of one causes downline transfers. A NETGETL 
or NETGTFL call causes downline transfers when the 
call is not made on list number 0. Other AIP calls 
do not necessarily cause immediate downline trans¬ 
fers, and downline data buffered by AIP might 
remain untransferred if the application program is 


taa-j 




59 39 30 18_0 


unused 

size^ 

unused 

address-i 


unused 

S'^^na 

unused 

addresSpg 


taa^ The symbolic address of the beginning of the array used in the NETPUTF call. 


size^ The length in central memory words of block fragment i. This field can contain the values 

1 _< size, < 63. The sum of all na values for size; defines the size in central memory 
words of tlTe block to transfer; this sum must be less than or equal to 410 central memory 
words. 

address^ The numeric relative address of the first word of the application program text area 

containing block fragment i. The text area addresses given in this field need not be for 
contiguous central memory areas. 


Figure 5-13. NETPUTF Statement Text Area Address Array 
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swapped out by the operating system. Downline data 
buffered by AIP might also remain untransferred if 
the application program schedules its own central 
processor usage with the COMPASS macro RECALL, 
instead of using calls to NETWAIT. To force the 
transfer of downline data buffered in AIP, call 
NETCHEK, (See Worklist Processing in section 4.) 

Figure 5-14 contains an example of NETPUTF use. 
The program sends a block containing an entire 
screen of data to an interactive console. AIP 
assembles the block from text areas containing one 
logical (and physical) line each. The application 
character type used for the block is 4. The pro¬ 
gram uses 12 text areas of separately addressed 
7-word arrays (OLINEl through 0LINE12), containing 
6-bit display code characters and 12-blt zero byte 
terminators (DATA statements). The text area 
address array, OTAA, contains 12 corresponding 
words; each word contains the relative address of a 
text area, obtained with the LOCF function. Because 
the array OTAA has a dimension of 12, a value of 12 
is assigned to ONA in its DATA statement. Only the 
first assignment statement constructing OTAA is 
shown. Because each text area contains seven words 
of ten 6-blt characters each, a size of 7 is 
declared in each OTAA entry. 


CONNECTIONS ON LISTS 

The two options for input from connections on lists 
are as follows: 

Fetch input to a single, unified buffer (NETGETL 
statement) 

Fetch input to an array of buffers (NETGTFL 
statement) 


Inputing to Single Buffer (NETGETL) 

You can use NETGETL to obtain an asynchronous 
supervisory message from application connection 
number 0. Application connection number 0 is 
always part of application list number 0. When a 
NETGETL call specifying input from list 0 is 
issued, any asynchronous supervisory messages 
queued for the program are returned before list 
scanning continues to other connection numbers on 
list 0. Synchronous supervisory messages and net¬ 
work data blocks on connection numbers other than 
zero can also^ be obtained when their connection 
numbers have been assigned to list 0. 


Each NETGETL call causes NAM to select (on a 
rotating basis) one of the logical connections from 
a specified list. NAM only chooses a connection 
that has network data blocks queued and that has 
not been turned off by a LST/OFF/R supervisory 
message. One network data block is transferred 
from the NIP queue of the selected connection for 
each call to NETGETL. The NETGETL call places the 
block header in the application program's header 
area and the block body in the application's text 
area. Figure 5-15 shows the format of the NETGETL 
statement. 


Each NETGETL statement causes the connection list 
to be scanned only once. Scanning begins with the 
connection immediately following the connection 
from which a block was previously transferred. The 
first connection on the list is examined after the 
last one on the list. Scanning ends when a con¬ 
nection with a queued input block is found. If no 
connection has a queued input block, scanning ends 
with the connection preceding the one at which 
scanning started. 


• 

DIMENSION OLINEl(7),...,0LINE12(7) 

INTEGER HA,OTAAC12),ONA,TERH(20) 

DATA ONA/12/,HA/0/,OLINEl/"ABCDEFGHIJL"12345678",0/,..., 
1.DATA 0HNE12/"ABCDEFGHIJ’',...,L"12345678",0/ 

• 

OTAAd )=SHIFT(6,30) .OR.LOCFCOLINEI) 


CALL NST0RE(HA,L"ABHABT",2) 

CALL NSTORECHA,L"ABHADR",TERM(IACN) 
CALL NST0RE(HA,L"ABHABN",1) 

CALL NST0RE(HA,L"ABHACT",4) 

CALL NST0RE(HA,L"ABHNFE",1) 

CALL NST0RE(HA,L"ABHTLC",840) 

CALL NETPUTF(HA,0NA,0TAA) 

• 


Figure 5-14. NETPUTF Statement FORTRAN 5 Example 
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CALL NETGETL(aLn,ha,ta,tLmax) 

aln An input parameter, specifying the number of the connection List to be scanned for a queued 
block. This parameter can have the values: 

0 Obtain all asynchronous supervisory messages queued on application connection 

number 0 first, then any data or synchronous supervisory message blocks queued 
on other connections on List zero. 

1 ^ aln ^ 63 Obtain one data or synchronous supervisory message block from one connection 
on the indicated List. 

ha A return parameter; as input to the call, the symbolic address of the application program's 

block header area. The header area always contains an updated application block header word 
after return from the call. 

ta A return parameter; as input to the call, the symbolic address of the first word of the buffer 

array constituting the text area for the application program. On return from the call, the text 
area contains the requested block if a block was available and the text area was Large enough. 
The text area identified by ta should be at Least tlmax words long. 

tLmax An input parameter, specifying the maximum Length in central memory words of a block the 

application program can accept. The value declared for tlmax should be Less than or equal to 
the Length of the text area identified in the same call; if tlmax is greater than the length of 
the text area, the block transfer resulting from the NETGETL call might overwrite a portion of 
the program. The maximum value needed for tlmax is a function of the block size used by the 
connection for input to the program and of the application character type the program has 
specified for input from the connection. The following ranges are valid: 

act=1 1 _< tlmax ^ 410 for 60-bit (one per word) transparent characters 

act=2 1 ^ tlmax ^ 273 for 8-bit (7.5 per word) ASCII characters 

act=3 1 ^ tlmax ^ 410 for 8-bit (5 per word) ASCII characters 

act=4 1 ^ tlmax ^ 205 for 6-bit (10 per word) display code characters 

A tlmax value of 0 can be Legally declared but results in an input-block-undeliverable 
condition; that is, an application block header is returned with an ibu value of 1, even when an 
empty block of application block type 2 is queued (a block with a tic value of 0). 


Figure 5-15. NETGETL Statement FORTRAN Call Format 


If data or supervisory message blocks are not 
available from any connection on the list, a null 
block is returned. A header word with an appli¬ 
cation block type of zero is placed in the header 
area, and the text area is unchanged from its 
content after the last block was obtained. Null 
blocks are not returned from each connection. 

The application program Indicates the size of its 
buffer in each NETGETL call. If a block larger 
than this size is available for transfer, the block 
remains queued, unless data truncation has been 
requested. AIP copies the header word of the block 
into the application program's block header area, 
sets the ibu bit of the header to one to Indicate 
the condition, and places the actual length of the 
queued block in the tic field of the header. The 
application program's text area is unchanged from 
what it contained after any previous transfer. To 
obtain the still-queued block, the program must 
issue a separate NETGET call, indicating a buffer 
size sufficient to accommodate the queued block, or 
it may request a truncated block using the DC/TRU/R 
asynchronous supervisory message (see section 3). 


The connection pointer within the list is incre¬ 
mented regardless of whether a transfer occurs, so 
the same connection is not Involved in a second 
NETGETL call. 

If the application program's text area is larger 
than the-block transferred by the NETGETL call, the 
portion of the text area after the last word used 
for the block remains unchanged from what it con¬ 
tained after any previous transfer. If the trans¬ 
ferred block does not completely fill the last word 
used for it, all character positions in the last 
word used are altered by the transfer. Only the 
leftmost character positions of the last word 
included in the block header word tic field value 
contain meaningful data. 

Figure 5-16 contains an example of NETGETL statement 
use. The program has assigned all interactive con¬ 
soles to list 0 when accepting connection with them 
(code not shown). A NETGETL call is used to 
periodically poll list 0 for asynchronous super¬ 
visory messages affecting new or existing connec¬ 
tions, and for Interactive input affecting passive 
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INTEGER TA(26),HA,TLMAX,0VTLMAX 
DATA HA/0/,TA/26*0/,TLHAX/13/ 

• 

NALN=0 

1 CALL NETGETL(NALN,HA,TA,TLHAX) 
IF(NFETCH(HA,L”ABHABT").EQ.O) GO TO 5 
IFCNFETCH(HA,L"ABHABT").NE.3) GO TO 4 
CALL SMP(HA,TA,TLMAX) 

GO TO 1 

4 IF(NFETCH(HA,L"ABHIBU").Ea,1) GO TO 3 

2 CONTINUE 


GO TO 1 

3 OVTLMAX=NFETCH(HA,L"ABHTLC")/7.5 
ATEHP=NFETCHCHA,L"ABHTLC")/7.5 
IF(ATEHP.NE.OVTLHAX)OVTLHAX=OVTLMAX + 1 
IF(OVTLHAX.GT.26) GO TO 9 
NACN=NFETCH(HA,L"ABHADR") 

CALL NETGET(NACN,HA,TA,OVTLHAX) 

• 

• 

GO TO 1 
5 CONTINUE 


Figure 5-16. NETGETL Statement 
FORTRAN 5 Example 


batch connections. The TLMAX value of 13 is 
adequate for both supervisory messages of appli¬ 
cation character type 1 and 72-character logical 
lines or a minimum-sized network block of 100 
characters in ASCII (application character type 2) 
from the interactive consoles. Each time list 0 Is 
polled by the NETGETL call, the block header area 


HA is tested to determine the block type. If a 
null block (ABHABT of 0) is found, polling ceases. 
If a block type of 1 or 2 is found, the block is 
processed (code not shown) and polling continues. 
If a supervisory message (block type of 3) is found, 
a subroutine called SUP is entered to process the 
supervisory message and polling of list 0 continues. 

The NETGET call recovers a block not delivered by 
the original call because the block was larger than 
expected. This condition is detected by the test 
of ABHIBU, as returned by the NETGETL call. The 
NETGET call is issued with more of the text area 
buffer available; OVTLMAX can be up to twice TLMAX 
before the text area is completely filled. 


Inputing to Fragmented Buffer 
Array (NETGTFL) 

You can use NETGTFL to obtain an asynchronous 
supervisory message from application connection 
number 0. Application connection number 0 is always 
part of application list number 0. When a NETGTFL 
call specifying input from list 0 is issued, any 
asynchronous supervisory messages queued for the 
program are returned before list scanning continues 
to other connection numbers on list 0. Synchronous 
supervisory messages and network data blocks on 
connection numbers other than- zero can be obtained 
when their connection numbers have been assigned to 
list 0. 

Each NETGTFL call causes NAM to select (on a 
rotating basis) one of the logical connections from 
a specified list. NAM only chooses a connection 
that has blocks queued and has not been turned off 
by a supervisory message. One block is transferred 
from the NIP queue of the selected connection for 
each call to NETGTFL; the block header is placed in 
the application program's header area and the body 
is placed in the application's text areas. Figure 
5—17 shows the format of the NETGTFL statement. 


CALL NETGTFL(aLn,ha,na,taa) 


aln An input parameter, specifying the number of the connection List to be scanned for a queued 
block. This parameter can have the values: 

0 Obtain all asynchronous supervisory messages queued on application connection 

number 0 first, then any data or synchronous supervisory message blocks queued 
on other connections on List zero. 

1 £ aln _< 63 Obtain one data or synchronous supervisory message block from one connection 
on the indicated list. 

ha A return parameter; as input to the call, the symbolic address of the application program's 

block header area. The header area always contains an updated application block header after 
return from the call. 

na An input parameter, specifying the number of fragments the block should be divided into. The 

number used should be the same as the number of central memory word entries in the text area 
address array identified by the taa parameter; if na is greater than the length of the text 
area address array, the block transfer resulting from the NETGTFL call might overwrite a 
portion of the program. Parameter na can have the values 0 £ na £-40. 

taa An input parameter, specifying the symbolic address of the first word of the one-dimensional 
array defining the application program's text areas. The array identified by taa has the 
format shown in figure 5-18. 


Figure 5-17. NETGTFL Statement FORTRAN Call Format 
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Each NETGTFL statement causes the connection list 
to be scanned only once. Scanning begins with the 
connection immediately following the connection 
from which a block was previously transferred. The 
first connection on the list is examined after the 
last one on the list. Scanning ends when a con¬ 
nection with a queued input block is found. If no 
connection has a queued input block, scanning ends 
with the connection preceding the one at which 
scanning started. 

The text areas used are defined for AIP by the text 
area address array, identified in the NETGTFL call. 
This text area address array has the format shown 
in figure 5-18. 

The application program indicates the total size of 
its text area buffers in each NETGTFL call through 
fields in the text area address array. If a block 
larger than this total size is queued from the 
specified connection, the block remains queued, 
unless truncation is in effect. (See section 3.) 
AIP copies the header word of the block into the 
application program's header area, sets the ibu bit 
of the header to one to indicate the condition, and 
places the actual length of the queued block in the 
tic field of the header. The application program's 
text areas are unchanged from what they contained 
after any previous transfer. To obtain the still- 
queued block, the program must issue a separate 
NETGETF call, indicating a buffer size sufficient 
to accommodate the queued block. The program also 
can request data truncation using the DC/TRU/R 
asynchronous supervisory message. (See section 
3.) The connection pointer within the list is 
incremented regardless of whether a transfer occurs, 
so the same connection is not involved in a second 
NETGTFL call. 


If the total size of the application program's text 
areas is larger than the block transferred by the 
NETGTFL call, the portions of the text areas after 
the last word used for the block remain unchanged 
from what they contained after any previous trans¬ 
fer. If the transferred block does not completely 
fill the last word used for it, all character 
positions in the last word are altered by the 
transfer. Only the leftmost character positions of 
the last word indicated by the block header word 
tic field value contain meaningful data. 

If data or supervisory message blocks are not 
available from any connection on the list, a null 
block is returned. A header word with an appli¬ 
cation block type of zero is placed in the header 
area, and the text areas are unchanged from their 
contents after the last block was obtained. Null 
(empty) blocks are not returned from each connec¬ 
tion. 


Figure 5-19 contains an example of NETGTFL use. 
The program previously assigned all Interactive 
consoles to list 0 when accepting connection with 
them (code not shown). A NETGTFL call is used to 
periodically poll list 0 for asynchronous super¬ 
visory messages affecting new or existing connec¬ 
tions, and for Interactive input affecting console 
connections. If the poll is successful (does not 
return a null block) and returns an asynchronous 
supervisory message block, subroutine SMP is called 
to process the message. If the poll returns a 
network data block header but no block (test of 
ABHIBU fails), a NETGETF call is Issued with a 
total text area buffer size larger than in the 
original call; this NETGETF call should successfully 
retrieve the queued block. 
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taa^ 

size; 


addressj 


The symbolic address of the beginning of the array used in the NETGTFL call. 

The length in central memory words of block fragment i. This field can contain the values 
1 < size,j < 63. The sum of all na values for size,; defines the size in central memory 
words of flTe largest block the call can transfer; this sum is the equivalent of the tlmax 
parameter in the-NETGETL statement. The sum of all na values for size can be 0, but this 
results in an input-block-undeliverable condition; that is, an application block header is 
returned with the ibu field set, even when an empty block of application block type 2 is 
queued (a block with a tic value of 0). 

The numeric relative address of the first word of the application program text area to 
receive block fragment i. The text area addresses given in this field need not be for 
contiguous central memory areas. 


Figure 5-18. NETGTFL Statement Text Area Address Array 


60499500 R 


5-13 













• 

DIMENSION LINE1<6),...,L1NE24(6) 

INTEGER HA,TAA(24),0VRFLNA 

DATA NA/12/,HA/0/,LINE1/6*L""/,...,LINE24/6*L"'7 

• 

TAACI)=SHIFT(6,30).OR.LOCFCLINEI) 

• 

NALN=0 

1 CALL NETGTFL(NALN,HA,NA,TAA) 
IF(NFETCH(HA,L"ABHABT").EQ.O) GO TO 5 
IF(NFETCH(HA,L"ABHABT">.NE.3) GO TO 4 
CALL SMP<HA,NA,TAA) 

GO TO 1 

4 IF(NFETCHCHA,L"ABHIBU").EQ.1) GO TO 3 

2 CONTINUE 

• 

• 

GO TO 1 

3 0VRFLNA=NFETCH(HA,L"ABHTLC")/60.0 
ATEMP=NFETCH(HA,L"ABHTLC")/60.0 
IF(ATEMP.NE.OVRFLNA)OVRFLNA=OVRFLNA + 1 
IF(0VRFLNA.GT.24) GO TO 9 
NACN=NFETCH(HA,L"ABHAOR") 

CALL NETGETFCNACN,HA,OVRFLNA,TAA) 

GO TO 2 

5 CONTINUE 


9 STOP 


Figure 5-19. NETGTFL Statement 
FORTRAN 5 Example 


NAM fragments the block transferred by the NETGTFL 
or NETGETF call Into 12 (NA) or more (OVRFLNA) text 
areas (LINEl through LINE24), Identified In the 
24-entry text area address array (TAA). Each text 
area Is Intended to hold one 60-character display 
coded physical line from a full page of input. NAM 
places each line into six consecutive central 
memory words. The calculation of OVRFLNA assumes 
that an application character type of 4 is used for 
input, but the size of the LINEl ' text area is 
adequate for both application character type 4 


lines and the application character type 1 words 
used for asynchronous supervisory messages. The 
FORTRAN function IDCF stores the address of each of 
the text area arrays in TAA, and the TAA entry has 
a corresponding length of 6; only the first TAA 
assignment statement is shown. 

PROCESSING CONTROL STATEMENTS 

The processing control statements NETFUNC, NETWAIT, 
NETSETP, and NETCHEK cause or reduce processing 
delays to alter the application program's effi¬ 
ciency. These statements are used in conjunction 
with the supervisory status word established by the 
application program in its NETON statement. 
NETWAIT and NETCHEK can be used by any application 
program; NETSETP is used only ' by programs 
performing parallel mode processing, as described 
in section 4. NETFUNC is used when the application 
wants to be swapped out or when it Issues a NETWAIT 
call if there is no deliverable data on a NETGETL 
or NETGTFL call. 

SUSPENDING PROCESSING (NETWAIT) 

The NETWAIT statement (figure 5-20) performs the 
following functions: 

.Allows an application program to have NAM 
request the operating system rollout or 
otherwise suspend the application program's 
processing 

Allows the application program to declare a 
mandatory wait before processing resumes 

Allows the application program to declare a 
maximum time for processing suspension 

Allows the application program to delay resump¬ 
tion of processing until input is available or 
deliverable through list processing for it on 
any of its logical connections, or on 
connection zero 

Causes the supervisory status word (NETON nsup 
parameter) for the program to be updated on 
return from the NETWAIT call 


CALL NETWAIT(time,fLag) 

time An input parameter, 1 ^ time_< 4095, specifying the number of seconds for which the application 
program should be suspended. If a value of zero is declared, a default value of one is used; 
if a value greater than 4095 is declared, a default value of 4095 is used. 

flag An input parameter, specifying the conditions under which processing should be resumed. This 
parameter can have the values: 

0 Return from NETWAIT call (resume processing) when input is available from any connec¬ 
tion, or when the period declared by the time parameter has elapsed. A minimum time 
of 1 second is used if input is not available immediately. When a flag value of zero 
is declared and input is available immediately, the value declared for the time 
parameter is ignored. 

1 Do not return from NETWAIT call (resume processing) until the period declared by the 
time parameter has elapsed, regardless of whether input is available from any 
connection. Also forces buffer output to be- transmitted. 


Figure 5-20. NETWAIT Statement FORTRAN Call Format 
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Calls to NETWAIT with nonzero flag values always 
suspend processing when suspension is possible. 
Calls to NETWAIT with zero flag values suspend 
processing only when no input is available. 

If NETFUNC is called with function code 1, calls to 
NETWAIT with zero flag values suspend processing if 
there is no input available or when no data is 
deliverable on a NETGETL or NETGTFL call. 

NETWAIT calls with a flag value of zero should only 
be made after all outstanding asynchronous super¬ 
visory messages have been fetched by the program. 
A NETWAIT call with a flag value of zero made while 
any asynchronous supervisory message remains queued 
always results in immediate return to the program, 
regardless of whether any other input is available. 
Such calls represent unnecessary additional proc¬ 
essing by AIP and the program and do not cause 
transfer of worklists that are not completely filled 
(effectively delaying output resulting from previous 
calls to NETPUT or NETPUTF). 

If NETWAIT is called while the program is operating 
in parallel mode, parallel mode operation is 
ignored, and the program is suspended. Parallel 
mode operation is reinstated when return from the 
NETWAIT call occurs. You should not issue a call 
to NETWAIT when it would interrupt parallel mode 
operation, unless a call to NETCHEK first returns 
an Indication that all worklist processing is 
completed. 

You should include NETWAIT calls in an application 
program that repeatedly polls the network for input 
(via NETGET, NETGETL, NETGETF, or NETGTFL calls). 
If such programs omit frequent NETWAIT calls, 
severe performance degradation can result; if you 
perform on-line debugging of such application 
programs, you should use small time limits for the 
job while it is in the debugging phase. 

You should use NETWAIT calls as part of the appli¬ 
cation program's mechanisms to control queuing. 
For example, the application program must be sure 
before each NETPUT or NETPUTF call that the call 
will not cause the logical connection's application 
block limit to be exceeded. When the limit has 
been reached, the application program should not 
output another block until it has received a block- 
delivered supervisory message for a block already 
sent. Because repeated polling for supervisory 
message input to obtain these acknowledgments can 
degrade program performance, a NETWAIT call should 
follow any NETPUT or NETPUTF call that might cause 
the limit to be reached. The time value declared 
in the NETWAIT call should be large enough to allow 
a block-delivered supervisory message to be received 
before another NETPUT or NETPUTF call occurs. 

Similarly, an application program should never 
enter parallel mode after a NETPUT call unless the 
program first issues a NETWAIT call. Because AIP 
does not transfer worklists partially filled by 
NETPUT calls, the NETWAIT call is necessary to 
force transfer of the worklist. (See Workllst 
Processing in section 4.) If NETWAIT is not called, 
the time between the NETSETP call and the first 
NETCHEK call is not used for network processing. 

Figure 5-21 contains examples of NETWAIT statement 
use. The program sends a series of data message 
blocks with NETPUT calls. Issues a NETWAIT that 
transfers the workllst and begins block trans¬ 
mission, and then checks the supervisory status 


MSK1=0"02000000000000000000" 

• 

CALL NETPUT(HA,TA,TLHAX) 

ITIME=1 

IFLAG=1 

CALL NETWAITCITIHE,IFLAG) 
IF(NSUP.ANO.MSKI.Ea.MSKI) GO TO 1 
ITIME=10 
IFLAG=0 

CALL NETWAITCITIME,IFLAG) 

1 IACN=0 

CALL NETGET (I ACN,HA,TA,TLI«IAX) 

CALL SNP(HA,TA,TLMAX) 

• 


Figure 5-21. NETWAIT Statement 
FORTRAN 5 Examples 

word (NSUP). If no asynchronous supervisory mes¬ 
sages are queued on return from the first NETWAIT 
call, no block-delivered message can have been 
received and the NSUP test falls. The program 
Issues a second NETWAIT call specifying delay until 
input on any connection (including the asynchronous 
supervisory message connection 0) is queued. 


CONTROLLING PARALLEL MODE (NETSETP) 

The NETSETP statement (figure 5-22) begins or ends 
an application program's parallel mode operation. 
Parallel mode operation involves workllst process¬ 
ing and is discussed in detail under both headings 
in section 5. While in parallel mode, an appli¬ 
cation program cannot use any AIP statements other 
than NETOFF or NETCHEK until AIP processing com¬ 
pletion has been indicated in the supervisory statuf 
word. 


CALL NETSETP(option) 

option An input parameter, specifying whether 
parallel mode operation begins or ends 
after the NETSETP call. This parameter 
can have the values: 

=0 Begin parallel mode operation. 

i^O End parallel mode operation. 

(This is the default value for 
application program operation.) 


Figure 5-22. NETSETP Statement 
FORTRAN Call Format 

The supervisory status word used during parallel 
mode operation is defined by the nsup parameter in 
the application program's NETON statement. The bit 
of the supervisory status word concerned with 
parallel mode processing is updated only while an 
application program is operating in parallel mode. 

When an application program is operating in parallel 
mode, it should not alter the contents of the text 
area used for a NETPUT or NETPUTF call immediately 
after that call. The program can normally reuse 
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the area as soon as a call to NETWAIT, NETGET, 
NETGETF, NETGETL, or NETGTFL is completed. The 
text area used in a NETPUT or NETPUTF call should 
not be altered until after workllst processing is 
reported complete; nor should the NETON call status 
word be tested until then. 

A call to NETSETP ending parallel mode operation 
should not be issued until a call to NETCHEK returns 
an Indication that all workllst processing is com¬ 
pleted. AIP ignores calls to NETSETP that-attempt 
to end parallel mode operation if the application 
program is not operating in parallel mode. • 

Figure 5-23 contains examples of NETSETP and NETCHEK 
use. The program attempts to reduce the number of 
workllst transfers between AIP and NIP to increase 
its efficiency. It does this while servicing a 
batch device on application connection number 2 and 
transmitting to a console on application connection 
number 3. 


IT LM AX =410 
IIACN=3 
I8ACN=2 
I0PT=0 

CALL NETSETP(IOPT) 

10 DO 99, I = 1, 5, 1 

CALL NSTORE(IIHA(I),L"ABHAOR",IIACN) 

CALL NSTORE(IIHA(I),L"ABHABN",I) 

CALL NETPUT (IIHA(I), ITEXT (20*CI-1))) 

88 ITEMP=NSUP.AND.SH1FT(1, 59) 

IFCITEMP.EQ.SHIFTCI, 59)) GO TO 99 
CALL NETCHEK 
GO TO 88 
99 CONTINUE 

98 ITEMP=NSUP.AND.SHIFT(1, 55) 

IFCITEMP.EQ.SHIFTCI, 55)) GO TO 3 
ITEHP=NSUP.AND.SHIFTC1, 56) 
IFCITEMP.EQ.SHIFTCI, 56)) GO TO 4 
ITIME=7 
IFLAG=1 

CALL NETWAITCITIME,IFLAG) 

GO TO 98 

3 IACN=0 
I0PT=1 

CALL NETSETPCIOPT) 

CALL NETGETCIACN, IHA, ITA, ITLMAX) 

• 

• 

4 I0PT=0 

CALL NETSETPCIOPT) 

CALL NETGETCIIACN, IIHAC1), ITEXT Cl), ITLMAX) 

5 CALL NETCHEK 
ITEMP=NSUP.AND.SHIFTC1, 59) 
IFCITEHP.NE.SHIFTC1, 59)) GO TO 5 


CALL NETCHEK 

ITEMP=NSUP.AND.SHIFTC1, 59) 
IFCITEHP.NE.SHIFTC1, 59)) GO TO 6 


GO TO 10 


Figure 5-23. NETSETP and NETCHEK Statement 
FORTRAN 5 Examples 


The program flow shown minimizes workllst transfers 
by concentrating the console output, instead of 
interleaving each output line with NETGET calls 
that might cause workllst transfers by AIP for 
workllsts not completely filled. Parallel mode 
does not expedite this efficiency, but requirements 
for its use are Illustrated in several parts of the 
code. 

When the program has sent downline all of the 
blocks It intends to send to the console, it tests 
for upline data or asynchronous supervisory mes¬ 
sages. If neither is found, NETWAIT rolls the 
program out for 7 seconds and suspends parallel 
mode processing temporarily. 

When asynchronous supervisory messages are found, 
the program leaves parallel mode processing with a 
nonzero lOPT parameter in another NETSETP call. 
The program can then fetch the messages without 
needing to test NSUP for completion of the NETGET 
call. 

When upline data is found, the program makes sure 
it is in parallel mode with a zero lOPT parameter 
in a NETSETP call. This call is ignored if it is 
reached by a path that had already caused parallel 
mode processing to begin. While in parallel mode, 
the program fetches any queued input from the con¬ 
sole. NETCHEK is called and tested for completion 
after the NETGET call. After the attempt to fetch 
data from the console is completed (the input dis¬ 
posed of by code is not shown), a similar attempt 
(not shown) is made to fetch data from the batch 
device. When any batch data has been disposed of, 
the program returns to its output loop for the 
console (having presumably prepared the output 
buffers first). 

If a system control point job is operating in 
parallel mode when it loses communication with NIP, 
all further network input and ouput AIP calls are 
ignored, but the program is not aborted. The 
program should check the n bit in the supervisory 
status word (see figure 5-2) after completion of 
all network input and output calls to determine 
whether or not it is still communicating with NIP. 

If a system control point job is not operating in 
parallel mode when it loses communication with NIP, 
it is aborted when it makes the next AIP request. 
The operating system aborts all nonsystem control 
point jobs when NIP aborts, regardless of operating 
mode. 

CHECKING COMPLETION OF WORKLIST 
PROCESSING (NETCHEK) 

The application program uses the NETCHEK statement 
(figure 5-24) to perform several functions. Each 
call to NETCHEK: 

Updates bit 59 of the supervisory status word 
(identified by the nsup parameter used in the 
NETON statement) on return from the call, when 
the program is in parallel mode 

Forces AIP to attempt transfer of its current 
workllst to NIP if the transfer has not yet 
occurred, if the program is running in either 
parallel or nonparallel mode 
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CALL NETCHEK 


Figure 5-24. NETCHEK Statement 
FORTRAN Call Format 


It Is not necessary to call NETCHEK to cause work- 
list transfers, Workllst transfers occur normally 
after all the requirements described In section 4 
under Workllst Processing have been met, A NETCHEK 
call causes an attempt to transfer a workllst in 
situations that do not meet these criteria. This 
operation is equivalent to a NETWAIT except that 
processing is not suspended. 


By checking the supervisory status word after each 
NETCHEK call, the application program can determine 
the most recent state of workllst processing and 
determine whether additional AIP routine calls can 
be Issued, NETCHEK, NETOFF, and NETWAIT are the 
only AIP statements that can be used while any 
workllst processing operation Is pending, A call 
to NETSETP ending parallel mode operation should 
not be Issued until a call to NETCHEK returns an 
indication that all workllst processing has been 
completed. 

If NETON Is called during parallel mode operation, 
NETCHEK should not be called until all workllst 
processing is reported complete. The NETON call 
status word does not contain meaningful Information 
until processing for the workllst containing the 
NETON call is complete, NETCHEK should not be 
called after a NETOFF call Is issued In parallel 


mode, A NETOFF call ends parallel mode operation 
by making workllst processing completion status 
Impossible, 

Workllst processing is described In section 4, The 
supervisory status word Is described under the 
heading Connecting to Network at the beginning of 
this section. Figure 5-23 contains examples of 
NETCHEK use. 


INITIATING SPECIAL AIP FUNCTIONS (NETFUNC) 

The NETFUNC statement (figure 5-25), when called 
with function code 1, indicates that the 
application program wants to be swapped out when it 
Issues a NETWAIT call, if there is no deliverable 
data on a NETGETL or NETGTFL call, 


CALL NETFUNC(netfc,netpa) 


netfc An input parameter, specifying that the 

application program wants to be swapped 
out when it issues a NETWAIT call if 
there is no deliverable data on a 
NETGETL or NETGTFL call. Only a value 
of 1 is accepted. All other values 
will be rejected. 

netpa Reserved for CDC. 


Figure 5-25. NETFUNC Statement FORTRAN 
Call Format 
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CHARACTERISTICS OF AN APPLICATION PROGRAM 


6 


This section describes the structure and. execution 
of a Network Access Method (NAM) application pro¬ 
gram. 


NOTE 

You cannot execute application pro¬ 
grams aa Transaction Facility tasks. 


NOS SYSTEM CONTROL POINT 
FACILITY 

The NOS system control point facility permits the 
exchange of data between programs running at dif¬ 
ferent control points. These programs are called: 

System control point jobs when they are formally 

defined as subsystems of the operating system 

User control point jobs when they exchange data 

with a system control point job 

System control point Jobs (subsystems) can make 
privileged requests to the operating system and 
execute with a very high priority. Network system 
control point jobs such as the Network Interface 
Program (NIP) usually reside In the operating system 
library. 

Application programs accessing the network execute 
as system control point jobs or user control point 
jobs using the system control point facility. Since 
the code that Implements this facility is embedded 
in the Application Interface Program (AIP), it 
remains transparent to the application program. 
Certain aspects of system control point jobs and 
user control point jobs, however, do affect appli¬ 
cation program operation. 

An application program cannot execute successfully 
unless the CUCP bit Is set In the access word 
associated with the user name of Its job. If the 
program attempts to access the network and the CUCP 
bit Is not set, the program is aborted with the 
dayfile messages ILLEGAL USER ACCESS and SYSTEM 
ABORT, and no error exit processing occurs. Access 
word bits are set through the MODVAL utility, as 
described in the NOS Analysis Handbook. 

While connection to the network exists, a network 
application program always has a minimum system 
activity count of one. If the application program 
uses the control point manager system macro call 
(GETACT), the minimum system activity count appears 
In the SCA field of the call. When a network 
application program ends its connection with the 
network by a NETOFF call, the system activity count 
drops to zero. The GETACT macro is described in 
volume 4 of the NOS reference set. 


BATCH JOB STRUCTURE 

A batch application program job using the Network 
Access Method Is structured like any other batch 
job. 

A job Is a sequence of commands, optionally followed 
by source programs, object programs, data, or 
directives. A batch job begins with the Job command 
and ends with an end-of-lnformatlon Indicator. Jobs 
can consist of either physical card decks or Images 
of card decks. 

Application program Jobs can enter the system In one 
of two ways: 

Batch jobs on cards are read In through card 
readers at the central site. Batch jobs of 
card Images are read from a load tape under the 
direction of the system console operator or the 
direction of another Job. 

Remote batch jobs on cards are read In through 
card readers at remote site terminals. Remote 
batch Job card Images are transmitted to form a 
file at the host computer. All remote batch 
jobs reach the host computer facilities through 
the Remote Batch Facility (RBF). 

Batch jobs have the same structure no matter what 
their origin. Remote batch jobs differ from central 
site batch Jobs In that output returns to the 
terminal and that remote Jobs are subject to the 
limitations of the physical equipment at the remote 
site. The following information about job decks 
applies to both card decks and card deck Images. 

The first card of the batch job deck Is the job 
command; the last card has a 6/7/8/9 multiple punch 
In column 1. Cards with a 7/8/9 or 6/7/9 multiple 
punch In column 1 divide the deck into a command 
portion, program portion, and optional data portion. 
When a job deck Is created as card images from a 
time-sharing terminal, the cEOR and cEOF entries 
result in the logical equivalent of 7/8/9 and 6/7/9, 
respectively. If the job deck Is submitted from a 
HASP or bisynchronous station through the Remote 
Batch Facility, the /*EORnn and /*EOI cards result 
in the logical equivalent of 7/8/9 and 6/7/8/9, 
respectively. HASP or bisynchronous station card 
readers and card punches support 7/8/9 cards but 
not 6/7/8/9 cards; 200 User Terminal card readers 
do not recognize either /*E0Rnn cards or /*E0I 
cards. 

Jobs in the system waiting to begin execution are 
collectively known as the Input queue. Each job 
enters the system with the user job name specified 
by the first command in the job deck. The operating 
system changes this name, based on the job command 
present, to distinguish it from all others in the 
system. 
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Once a job enters central memory and begins execu¬ 
tion, the image of the job deck is known as a file 
by the name of INPUT. During job execution, a file 
with the name of OUTPUT is generated. When the job 
completes execution, file OUTPUT becomes part of 
the output queue. The output queue is the collec¬ 
tive name for output files remaining in the system 
when the jobs that generated them have completed 
execution. As printers, punches, or remote -devices 
become ready, the operating system or remote batch 
software causes files from the output queue to be 
physically output. Such files normally return to 
the user with the system-generated name of the job 
that created them. 


COMMANDS 

Commands are instructions to the operating system 
or its loader. They are grouped together at the 
beginning of a deck. Collectively, the commands 
form a job stream. 

Commands execute in the order in which they appear 
in the job stream, unless that order is modified by 
the operating system control language. Conse¬ 
quently, the order of the commands governs the order 
of other sections in the deck. 

The user is responsible for structuring the job 
decks so that each command read from file INPUT 


corresponds correctly with the sections of the job 
deck. The operating system handles each section of 
the job deck only once, unless the job specifies 
contrary handling. 


The job command portion of an application program 
job deck normally contains a USER command as its 
second card. (See figure 6-1.) The user - name 
specified in this command must have bit 11 (CUCP) 
of its corresponding access word set, so that the 
application program can successfully complete calls 
to system control points. The NOS ' Analysis 
Handbook describes the mechanism for setting access 
word bits. Some installations require a CHARGE 
command following the user command. 


Until the program is successfully compiled, the only 
other required command is a compiler or assembler 
execution command in the form described in the 
appropriate reference manual for the product being 
used. Figure 6-1 Illustrates the use of the com¬ 
piler execution command for FORTRAN 5. If the job 
uses a compiler, a LIBRARY or LDSET command is 
needed to satisfy externals from local libraries 
NETIO or NETIOD. If the job uses COMPASS, the 
COMPASS command must declare NETTEXT to satisfy AIP 
externals and to define- the symbolic names used for 
the field access macro utilities NFETCH and NSTORE, 
(See section 4.) 
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JOB IDENTIFICATION 

The network software Identifies an application 
program and issues dayfile messages concerning the 
program on the basis of the aname parameter used in 
the program's NETON call. The operating system, 
however, is unaware of this name and Issues dayfile 
messages on the basis of the job name assigned to 
the program according to the contents of the job's 
command portion. To ensure that all dayfile mes¬ 
sages concerning the application program can be 
Identified, you should take the following steps when 
the program is run as a batch job: 

Determine the method NOS will use to assign a 

job name to the application program. 


Determine the first four characters of that 
name. 


Inform the host operator of the first characters 
of the job name corresponding to the application 
name. 


Do not thereafter alter the portion of the job 
commands that determines the job name. 


Alternatively, you can use the NOS control point 
manager macro GETJN to determine the job name 
assigned to the application program job during each 
execution. For the host operator's information, 
this name can then be entered in the system dayfile 
with a message indicating its application program 
name equivalent. This operation can be performed 
with the NOS system macro MESSAGE. GETJN and 
MESSAGE are described in volume 4 of the NOS 2 
reference set. 


PROGRAM CONTENT 

If the job contains commands to reprieve Itself from 
an abort (RERUN or RESTART), the program portion of 
the job must issue a NETOFF and a new NETON call in 
order to continue accessing the network through NAM. 

When an application program is structured to use 
overlays, the common blocks used by all AIP routines 
must reside in the main (zero-level) overlay. The 
operating system loader places the blocks in the 
main overlay only if the application program makes 
at least one call to an AIP routine other than 
NETCHEK in the main overlay. At a minimum, the 
NETON call must therefore be placed in the main 
overlay of the program. 


PROGRAM EXECUTION THROUGH lAF 

Your application program can be executed from the 
Interactive Facility in several ways: 

- As a SUBMIT command file hatch job 

- As a ROUTE command file batch job 

- As an Interactive job 

- As a detached interactive job (so your 
terminal can log in to it) 

The use of SUBMIT and ROUTE is described in volume 
3 of the NOS reference set. SUBMIT and ROUTE 
command file jobs have the same command content 
requirements as other batch jobs. 

Figure 6-2 shows the procedure for interactive 
execution of the sample program RMV2 (chapter 8). 
Detached interactive job programs have the same 
program content requirements as batch job programs. 


Your entries are underlined: 

/ get^rmvZ -- Get indirect access source file 

/ cobol5,i=rmv2^lo=0,b=zap -m - Compile it 

071600B CM, 2.327 CPS, OOOOOOB ECS 
/ftn5,i=rmv2,lo=0,b=zap 

0.(J23 CP SECONDS COMPILATION TIME. 

/ ldset,lib=netiod -Load it 

LDR>? zap .—---- Execute it 

%e —- Bypass the lAF input queue to find out if the job step was 

successful 

JSN: AAEQ SYSTEM: BATCH SRU: 11.398 

STATUS: NETON WITH NIN = 551 

W--- Detach the running (rolled out) application program 

JOB DETACHED, JSN=AAEQ 

JSN: AAFO, NAHIAF 

RECOVERABLE JOB(S) 

JSN UJN STATUS TIMEOUT 

AAEO AKLQ EXECUTING 


Figure 6-2. Interactive Program Execution Procedure Example (Sheet 1 of 2) 
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ENTER GO TO CONTINUE CURRENT JOB, 

RELIST TO LIST RECOVERABLE JOBS, 

OR DESIRED JSN: a£-«- Startup a new job so you can switch applications 


/ bye,rmv2 --Use an lAF application switch command 

UN=xxxxxx LOG OFF 08.48.49 

JSN=AAF0 SRU-S= 1.009 

CHARACTERS= 0.381KCHS 

lAF CONNECT TIME 00.11.02 

THIS IS RMV2 USING QTRH. ENTER SOMETHING 

shutdown -Respond to RMV2 prompt with command that shuts it down • 

BYE FOREVER! 

SHUTDOWN COMING 

RMV2 CONNECT TIME 00.02.01 

JSN: AAGN, NAHIAF -«- Connection switch back to lAF is automatic 

RECOVERABLE JOB(SI 

JSN UJN STATUS TIMEOUT 

AAEQ AKLQ SCH ROLLED 


ENTER GO TO CONTINUE CURRENT JOB, 

RELIST TO LIST RECOVERABLE JOBS, 

OR DESIRED JSN: aaeq -Recover the detached application program (has called NETOFF, 

so this rollout is controlled by lAF) 

JSN: AAEQ SYSTEM: BATCH SRU 11.799 
STATUS: 

CHARACTER SET: NORMAL MODES: PROMPT ON 
JOBS IN SYSTEM. 

ACSC, T , 11.799UNTS. 

/ enquire,f -- Here are all the files NETIOD should create 


LOCAL FILE INFORMATION. 


FILENAME 

LENGTH/PRUS 

TYPE 

STATUS 

INPUT* 

1 

IN.* 

EOR 

RMV2 

37 

LO. 

EOR 

INPUT 


TT. 


ZZZZZDN 

3 

LO. 

EOR WRITE 

ZZZZZSN 

2 

LO. 

EOR WRITE 

ZAP 

27 

LO. 

EOF 

OUTPUT 


TT. 



LEVEL 


TOTAL = 7 


Figure 6-2. Interactive Program Execution Procedure Example (Sheet 2 of 2) 


TYPES OF APPLICATION 
PROGRAMS 

All application programs should be specified in 
COMTNAP. When an application is defined also in 
the local configuration file it can be declared as 
having one of the following attrlbiites: 

Disabled 

Unique Identifier 
Privileged 
Request startable 

Have more than one copy on any one host 


Access to an application program can also be con¬ 
trolled . A program can be: 

A restricted access or general access appli¬ 
cation program 

A mandatory or primary application program 

These access types are separately established for 
each connection with the program. The first type 
is controlled through the user name associated with 
the connection. The second type is controlled 
through the terminal device name associated with 
the connection. 
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DISABLED 

A disabled application is configured in the network 
but Is not allowed to access the network until the 
host operator enters an enable command to allow It 
to be connected. 


UNIQUE IDENTIFIER 

A unique Identifier application program requires 
that Interactive console user access to it be 
restricted on the basis of the login parameters 
used. Only one interactive console with a given 
combination of family name and user name index can 
be connected with a unique identifier application. 
NVF rejects a terminal user's request to be con¬ 
nected with a unique Identifier application if the 
user logs in with a family name and user name index 
combination used by a console that is already con¬ 
nected with the application. NVF tells the terminal 
user to try again later. 

As an example, the Remote Batch Facility (RBF) 
routes its output files on the basis of the family 
and user names used when the terminal console logs 
in. So that output will not be mlsrouted, RBF is 
normally configured as a unique Identifier appli¬ 
cation program. Thus the family name and user name 
index combinations of all consoles accessing the 
program are guaranteed to be unique. 

PRIVILEGED 

Privileged application programs must have an SSJ= 
entry point to access the network successfully. 
They also often have the CSOJ bit set in the access 
word associated with the user name for the Job 
executing the program code. 

The CSOJ bit provides the program with system 
origin type permission. Jobs with system origin 
type permission can be executed by host operator 
type-in. Such jobs usually reside under the 
operating system user name in the operating system 
permanent file catalog or are Installed in the 
operating system library. 

Having system origin type permission does not mean 
that these programs must have a system origin type 
when executed; rather, a privileged application 
program is capable of such execution. 

Nonprlvlleged application programs can have any 
origin type permission but do not contain an SSJ= 
entry point. Origin type permission for such 
programs does not affect access to the network. 

The primary reason for defining an application 
program as privileged is to help ensure network 
security. Nonprlvlleged application progams cannot 
run with the application program name used for a 
privileged application, even if the privileged 
application program is not currently running. 

Application programs usually become privileged when 
they are Installed in the system. An Installed 
application program is one that resides in the 
operating system library. The procedure file used 
to execute an Installed application program must 
have the GASF bit set in the access word associated 
with the user name in the file. Jobs that attempt 


to access Installed application programs must also 
have the CASF bit set in the access words associated 
with their user names. This bit must be set for 
access to the system library. 

If a privileged application program with the CSOJ 
bit set has not been installed in the system 
library, it can be executed by a host operator 
type-in that invokes its procedure file. The type- 
in used has the form: 

X. BEGIN ( ,anamep ) 

where the anamep parameter is the name of the 
procedure file. ■The procedure file must be a 
permanent file in the operating system permanent 
file catalog (stored under the system user name and 
user index). For the anamep value, you can use a 
variant of either the program entry point name or 
the program network application name (NETON state¬ 
ment aname parameter), and all three identifiers 
should be coordinated. CDC-written application 
programs are Invoked through procedure files for 
which certain naming conventions have been adopted. 
These conventions appear in the NOS Installation 
Handbook, described in the preface. Similar 
conventions could be adopted for site-written 
application programs. 

An Installed privileged application program with 
the CSOJ bit set can be executed by a host operator 
type-in of the form: 

X.anament. 

where the anament parameter is the name of the 
program (first entry point) installed in the 
library. For the anament value, you can use a 
variant of the program network application name 
(NETON statement aname parameter). 

A privileged application program with the CSOJ bit 
set that is not installed can be executed by a 
system console operator type-in that Invokes an 
installed procedure file. This type-in has the 
form: 

X. anamep. 

where the anamep parameter is the name of the 
procedure file Installed in the system library. 
For the anamep value you can use a variant of 
either the program entry point or the program 
network application name (NETON statement aname 
parameter), and all three identifiers should be 
coordinated. As described previously, the naming 
conventions used by CDC for CDC-written application 
programs should be used as a guide for procedure 
files Invoking site-written application programs. 

Privileged application programs with the CSOJ bit 
set can be automatically started when the host's 
network software is started. This process is 
described in the NOS Administration reference 
manual. 

You should not define an application program as 
privileged or Install it in the system library 
until the program has been thoroughly debugged. 
Programs should be run with batch, remote batch, or 
detached Interactive job origin during the 
debugging process. 
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REQUEST STARTABLE 

Whenever the application is requested by a terminal 
user (through the application name in the login 
process), or by another application (by a CON/ACRQ 
message), NVF attempts to start the application. 

The file name equivalent to the name of the appli¬ 
cation should be made available to NVF through the 
NVF startup record. (See the NOS Installation 
Handbook.) 

HAVE MORE THAN ONE COPY 
(ON ANY ONE HOST) 

More than one copy of an application program is 
allowed to be simultaneously connected to the net¬ 
work, if so specified in the local configuration 
file. If such an application is also request 
star table, then NVF will start up a new copy of an 
application whenever a connection request for the 
application comes into the host, and all existing 
copies already have their maximum number of 
connections. 


RESTRICTED OR GENERAL ACCESS 

Each user name in the host can be validated to 
connect to one or any application in the network. 
This validation is done through MODVAL, which is 
described in the NOS Administration reference 
manual. 


MANDATORY OR PRIMARY 

In the local configuration file, each terminal 
console can be designated to have a mandatory or a 
primary application assigned to it. If the appli¬ 
cation is mandatory, the terminal cannot be logged 
into any other application regardless of the user 
name entered. If the application is primary, the 
terminal will automatically be connected to the 
application on the initial login unless an alternate 
application name is entered during the login. For 
subsequent connections, the network will prompt for 
an application and, if a carriage return is entered, 
the network will connect the terminal to the primary 
application. 


DEBUGGING APPLICATION 
PROGRAMS 

Application program job content partially depends 
on the purpose of the job's execution. If the job 
is executed for debugging purposes, the debugging 
method chosen for the program can affect the param¬ 
eters specified in the job's LDSET or LIBRARY 
command and thereby affect the AIP code executed at 
the program's control point. This aspect of execu¬ 
tion is discussed in the next subsection. 

Successful execution of an application program 
depends on several conditions beyond the scope of 
the program's code. The less obvious of these 


dependencies are discussed later in this section; 
these dependencies are primarily requirements for 
proper configuration of the program and the ter¬ 
minals it services. 


FATAL ERRORS 

Portions of the Network Access Method issue 
diagnostic messages for all fatal errors. These 
messages are described in appendix B. 

The form used for AIP and QTRM diagnostics depends 
on the library used to load the routines used during 
execution. When NETIO is used in the LIBRARY or 
LDSET command, a single diagnostic message with a 
reason code is written to the program dayfile before 
the program is aborted by a fatal error. When 
NETIOD is used, the same diagnostic is issued, but 
supplementary diagnostics can also be Issued before 
the program aborts. 


DEBUGGING METHODS 

Two methods are available for debugging the con¬ 
nection servicing logic of an application program: 

Supervisory and/or data message flow through 
the program can be traced by optional AIP code; 
this code creates a log file of such messages. 

Statistical information on program execution 
can be gathered for performance adjustment by 
optional AIP code; this code creates a statis¬ 
tics file of the program's network use. 


Debug Log File and Associated Utilities 

The optional AIP code that creates the log file 
gives an application program a means of recording 
all exchanges between the program and the network. 
The AIP utility routine NETDBG gives the program a 
method of selecting exchanges that should be 
recorded. A running count of the number of mes¬ 
sages copied to the debug log file is kept in the 
supervisory status word (NETON nsup parameter). 
This count enables the application to decide when 
to call the AIP utility routine NETREL, which gives 
an application program a way of releasing, saving, 
or processing the current information in the debug 
log file. The AIP utility routine NETSETF gives an 
application program a way of requesting the opera¬ 
ting system to flush the Input/output buffer for the 
debug log file automatically, if the application 
terminates abnormally. The AIP utility routine 
NETLOG allows the application to enter messages into 
the debug log file. 

Whether or not the log file is created depends on 
the system library used to satisfy the application 
program's externals. AIP code for the program can 
be loaded from either NETIO or (if the installation 
elects to install it) from NETIOD. When NETIOD is 
used, all code needed to create the log file is 
loaded; the options for logging both supervisory 
messages and network data blocks are automatically 
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turned on Initially. Because this code causes 
additional processing overhead and central memory 
requirements for the application program's control 
point, you might want to remove the code after the 
program Is completely debugged. You can remove the 
code from the job without altering the application 
program's structure by loading the AIP code from 
NETIO instead of NETIOD. When NETIO Is used, the 
only parts of the log file code loaded are 
do-nothing versions of NETDBG, NETLOG, NETREL, and 
NETSETF. 


NETDBG Utility 

When NETIOD is used, the log file is automatically 
created without application program calls. You can 
use calls to NETDBG to switch either or both options 
for message logging off and back on throughout the 
program. 

NETDBG calls use the same syntax and calling 
sequences as other AIP calls. (See sections 4 and 
5.) Figure 6-3 shows the NETDBG utility FORTRAN 
call statement format. NETDBG can only be called 
after NETON is called and before NETOFF is called. 

Calls to NETDBG can occur In programs using either 
NETIO or NETIOD. For example, when a NETDBG call 
turns either or both supervisory message and net¬ 
work data block logging on and a status is returned 
indicating logging is not possible, no error occurs 
and the option selection is ignored. When the 
program contains a NETDBG call before NETON to turn 
both logging options off and a status is returned 
indicating logging is possible, a log file is still 
created to contain a record of the program's NETON, 
NETDBG, and NETOFF calls. 


NETREL Utility 

Log file creation begins when the application 
program successfully completes its NETON call and 
ends when NETOFF is issued. If the application has 
not called NETSETF previously and the program 
falls, the output buffer used for the log file is 
not completely emptied into the file. In such a 
case, the application should reprieve Itself and 
issue a NETOFF call, or a NETREL call, to flush the 
Input/output buffer. 

NETREL calls use the same syntax and calling 
sequences as other AIP calls. (See sections 4 and 
5.) Figure 6-4 shows the NETREL utility FORTRAN 
call statement format. To use the NETREL utility, 
an application must issue an initialization call to 
NETREL with a nonzero first parameter. This call 
must be issued before NETON and any NETSETF call in 
order to set up the ZZZZZDN file correctly. 

The first parameter on the NETREL call is the name 
of a file containing a job command record. If the 
file name supplied does not conform to the NOS 
operating system file name format, NOS aborts the 
job when AIP attempts to do Input/output on the 
file. NETREL reads up to 192 central memory words 
of the named file, or until a logical end-of-record 
is encountered. 


CALL NETDBG(dbugsup, dbugdat, avail) 


dbugsup An input parameter that turns the 

logging of supervisory messages on or 
off. This parameter can have the 
values: 

=0 Turn supervisory message 

logging on. 

^0 Turn supervisory message 

logging off. 

When supervisory message logging is 
turned on, all supervisory messages 
(except block-delivered messages) 
exchanged on connection 0 between the 
application program and NAM are log¬ 
ged. Logging occurs whenever a call 
to NETGET, NETGETL, NETGETF, NETGTFL, 
NETPUT, or NETPUTF causes a message 
transfer. This logging continues 
until a call with a nonzero debugsup 
parameter is'issued. 

dbugdat An input parameter that turns the 
logging of data messages on or off. 
This parameter can have the values: 

=0 Turn network data block 
logging on. 

/O Turn network data block 
logging off. 

When network data block logging is 
turned on, all network data blocks 
exchanged on any connection between 
the application program and NAM are 
logged; block-delivered supervisory 
messages (FC/ACK/R) are also logged, 
regard less of the value specified 
for the dbugsup parameter. Logging 
occurs whenever a call to NETGET, 
NETGETL, NETGETF, NETGTFL, NETPUT, 
or NETPUTF causes a block transfer. 
This logging continues until a call 
with a nonzero dbugdat parameter is 
issued. 

avail A return parameter that indicates 

whether the logging code portion of 
AIP was loaded when the program was 
loaded. On return from the call, 
this parameter can have the values: 

=0 Loading occurred from NETIOD 

and logging is possible. 

=1 Loading occurred from NETIO 

and logging is not possible. 

When a value of 1 is returned, speci¬ 
fication of 0 for either dbugsup or 
dbugdat has had no effect but does 
not cause an error. 


The second parameter on the NETREL call gives the Figure 6-3. NETDBG Utility FORTRAN Call 

maximum number of words in each message to be saved Statement Format 

in the ZZZZZDN file. 
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CALL NETREL(lfn,msglth,nrewind) 

Lfn 

An input parameter that names the 
file containing the job record to be 
copied to the ZZZZZDN file. This 
parameter can have the values: 


=0 

The application program job 
provides its own disposition 
of the file ZZZZZDN. Only 
the msglth parameter is proc¬ 
essed by AIP. 



The named file contains a job 
record to dispose of the file 
ZZZZZDN. The value declared 
for lfn must be left-justified 
with zero fill, and can be one 
to seven alphabetic or nuneric 
characters in any combination 
permitted by the NOS operat¬ 
ing system file name format. 

msglth 

An input parameter that gives the 
maximum number of words of each mes¬ 
sage to be saved on the ZZZZZDN file; 
0<msglth<410. The value is ignored 
if msglth is 0. 

nrewind 

An input parameter that controls 
whether AIP rewinds the job command 
record file before the NETREL oper¬ 
ation begins. This parameter can 
have the values: 


=0 

File lfn is rewound before 
any operation is performed. 



File lfn is not rewound be¬ 
fore any operation is per¬ 
formed. 


If the value declared for lfn is zero, 
a value of zero for the rewind para¬ 
meter is ignored. 


Figure 6-4. METREL Utility FORTRAN Call 
Statement Format 


If NETREL is not called and the application is 
loaded with NETIOD, the debug log file exists as a 
locai file assigned to the application job. The 
debug log file does not begin with a job command 
record; therefore, at job termination it should be 
treated (disposed of) as a normal local file. 


NETSETF Utility 

NETSETF calls use the same syntax and calling 
sequences as other AIP calls. (See sections 4 and 
5.) Figure 6-5 shows the NETSETF utility FORTRAN 
call statement format. NETSETF allows the input/ 
output buffer for the debug log file ZZZZZDN to be 
flushed automatically, if the application terminates 
abnormally. If the error flag code is greater than 
23 octal (the COMPASS EREXIT mnemonic SPET), then 
the debug log file is not flushed. See volume 4 of 
the NOS reference set for a list of the vaiues for 
the error flag code. Flushing sets the flush bit 
in the file environment table (FET) for the debug 
log file and calls the NOS macro SETLOF. 


CALL NETSETF<flush,fetadr) 

flush 

An input parameter that flushes the 
debug log file automatically upon 
abnormal termination. The flush 
parameter can have the following 
values: 


=0 the flush bit is set in the 

FET and the FET address of 
the debug log file is re¬ 
turned in fetadr. 


/O the flush bit is set in the 

FET and the SETLOF macro is 
called. The FET address is 
not returned. 

fetadr 

A return parameter that is the FET 
address of the debug log file re¬ 
turned by NAM. If zero, either the 
flush parameter was nonzero or NETIO 
was loaded (in which case the flush 
parameter makes no difference). 


The third parameter in the NETREL call determines 
the position at which NETREL begins reading the 
named file. The file can be rewound to the 
beginning-of-information before reading begins, or 
it can be read from its current position. 

After copying the job command record file to the 
debug log file, AIP writes an end-of-record level 0 
to the debug log file before beginning to log mes¬ 
sages. Each call to NETREL zeros the MC field in 
the supervisory status word (NETON nsup parameter). 
Subsequent calls to NETREL route ZZZZZDN to the 
input queue, reinitialize the file environment 
table and MC field in the supervisory status word, 
and copy another job command record to a new 
ZZZZZDN file. 


Figure 6-5. NETSETF Utility FORTRAN Call 
Statement Format 

The SETLOF macro provides NOS with a list of files 
and FET addresses to be flushed on abnormal ter¬ 
mination. The SETLOF macro can be called more than 
once; each successive call overrides the previous 
call with a new list of files. 

Applications written in FORTRAN or COBOL should not 
call NETSETF, because those compilers use CYBER 
Record Manager, and CYBER Record Manager also calls 
the NOS macro SETLOF. If you want the application 
to call the SETLOF macro and include the debug log 
file in the SETLOF macro list, the application can 
first call NETSETF to get the FET address of the 
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debug log file. If NETSETF is not called and you 
want an application to flush the debug log file on 
abnormal termination, then the program must 
reprieve itself and call NETOFF or NETREL. NETSETF 
needs to be called only once and should be called 
before NETON is called. NETREL does not clear the 
flush bit in the FET when it reinitializes the FET. 


NETLOG Utility 

NETLOG calls use the same syntax and calling 
sequences as other AIP calls. (See sections 4 and 
5.) Figure 6-6 shows the NETLOG utility FORTRAN 
call statement format. NETLOG allows an application 
to enter messages into the debug log file. These 
messages can be of any size, but large messages 
degrade the performance of AIP. Messages are copied 
to the debug log file unchanged. However, they are 
truncated if the NETREL utility has previously been 
called and if the message length exceeds the number 
of central memory words specified as the maximum 
message length in the NETREL call. The messages 
can be either formatted or unformatted. 


CALL NETLOG (address,size,format) 

address 

An input parameter that gives the 
address of the message to be written 
to the debug log file. 

si ze 

An input parameter that gives the 
size in central memory words of the 
message to be written to the debug 
log file. 

format 

An input parameter that determines 
whether the message is formatted or 
unformatted. This parameter can have 
the values: 


=0 The message is unformatted 

and will be printed by DLFP 
in octal, hexadecimal, 6-bit 
display code characters, and 
ASCII characters. 


=1 The message is formatted and 

will be printed unchanged by 
DLFP. 


Figure 6-6. NETLOG Utility FORTRAN Call 
Statement Format 


NETDMB Utility 

NETDMB calls use the same syntax and calling 
sequences as other AIP calls. (See sections 4 and 
5.) Figure 6-7 shows the NETDMB utility FORTRAN 
call statement format. NETDMB allows an application 
to dump its exchange package and central memory 
field length into the local dump file ZZZZDMB. The 
data is in binary format. The file ZZZZDMB must be 
postprocessed by a binary dump interpreter to allow 
selection of address range and formatting for print. 
The dump formatting is done through DSDI, which is 
described in the NOS 2 Analysis Handbook. A 
logical end-of-record is written to the file 
ZZZZDMB after each NETDMB call. 


CALL NETDMB(dumpid,ecs) 

dumpid 

An input parameter that is an octal 
6-digit dump identifier number. The 
dumpid parameter can have the values 

0 <_ dumpid < 777777. 

ecs 

An input parameter that determines 
whether the associated extended 
central storage is also dumped. This 
parameter can have the values: 


=0 Do not dump extended central 

storage 


/O Dump the associated extended 

central storage 


Figure 6-7. NETDMB Utility FORTRAN Call 
Statement Format 


Debug Log File Postprocessor Utility 

The debug log file is a binary compressed file; it 
is written using NOS data transfer macros. You can 
obtain a listing of this file by running the debug 
log file postprocessor utility with the desired 
options. 

The debug log file postprocessor (DLFP) utility is 
a program that processes the debug log file genera¬ 
ted by AIP. The general format of the DLFP command 
is shown in figure 6-8. Examples of DLFP commands 
are shown in figure 6-9. 


Formatted messages are stored as 6-bit display code 
characters with zero byte terminators. The first 
character of the message is used--as a carriage 
control character for the line and is not printed. 
Formatted messages longer than 136 characters 
should be stored as separate zero-byte-terminated 
1ines. 

DLFP prints formatted messages unchanged. DLFP 
prints unformatted messages the same way it prints 
network message text (in octal, hexadecimal, display 
code, and ASCII characters). 

NETLOG cannot be called before NETON. 


The debug log file postprocessor automatically 
rewinds the debug log file before postprocessing 
begins. The application programmer needs to rewind 
the file only when DLFP is not the first software 
to access the file after program execution com¬ 
pletes . 


The debug log file can be copied-, made permanent, 
or otherwise accessed before DLFP begins its post¬ 
processing. Such operations, however, must not 
alter the form of the file used for DLFP input. 
You cannot copy portions of the file and success¬ 
fully run DLFP using Che Incomplete copy. 
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The job command 

format for DLFP is: 

DLFP(pi,P2,P3 


is any of 
order: 

the following parameters in any 

I=lfni 

Directives comprise the next 
record on file Ifn^. 

1=0 

No directive input. 

I omitted 

Directives on file INPUT. 

L=lfn2 

List output on file lfn 2 . 

L omitted 

List output on file OUTPUT. 

B=lfn3 

File lfn 3 contains the debug log 
file. 

B omitted 

Debug log file is ZZZZZDN. 

D 

Discontinue processing current 
directive record if there are 
errors in it. Restart with next 
directive record if any. 

D omitted 

Do not ignore directive errors; 
abort job. 

N=1fn^ 

Create new debug log file Ifn^ 
with records selected from Ifnj 
or ZZZZZDN according to direc¬ 
tives governing record selection 
for the list output file. If 
this option selected, no debug 
log file data is written on the 
list output file. 

N omitted 

No new debug log file is 
created. 

File names must 
format. 

comply with the NOS product set 


Figure 6-8. DLFP Command General Format 


The N option of the DLFP command provides a means 
for creating a new debug log file that is a subset 
of an existing debug log file. The new file can be 
separately processed by a subsequent DLFP command 
and separate DLFP directives. 

An optional directive file can be submitted to the 
DLFP to select special supervisory messages or net¬ 
work data blocks for output. The directive file 
can have zero or more directive records. 

Each directive record is a Z type record, which can 
contain one or more keywords starting in card image 
column 1. Keywords allow you to select which 
supervisory messages or network data blocks are 
written to the output file. All keywords are 
optional and can appear In any order. You can use 
one or more blanks, or a comma followed by zero or 
more blanks, to separate the keywords. You can use 


DLFP(I=0,B=TAPE) DLFP reads the debug log 
data from file TAPE. The 
entire log file is processed 
and written to output. The 
output goes to the OUTPUT 
fi le. 

DLFP<D,L=SAVE) DLFP reads the debug log 

data from file ZZZZZDN. 

DLFP reads the INPUT file 
looking for directives. If 
the directives are not 
correct, DLFP ignores them. 
The output goes to file 
SAVE. 

DLFP<I=OIR,B) DLFP aborts with the fatal 

error message PARAMETER 
FORMAT ERROR because there 
is no file associated with 
the B parameter. If the B 
parameter is specified 
correctly, DLFP reads file 
DIR looking for directives. 
If the directives are not 
correct, DLFP aborts. 


I 


I 


Figure 6-9. DLFP Command Examples 


leading blanks. Figure 6-10 shows the general for¬ 
mat of DLFP directive keywords w1 th examples of 
them in figure 6-11. 

Each directive record Initiates an Independent 
search. An empty directive file or empty directive 
record or 1=0 causes all debug log file blocks to 
be output. Directive records are copied to the 
output listing file. 

DLFP Issues dayfile messages to inform users of 
fatal errors or processing completion. Appendix B 
lists all dayfile messages issued by DLFP. Errors | 
or informative messages can be writtento the output 
file by DLFP. All messages except NO MESSAGES 
FOUND are fatal errors and cause the job to be 
aborted unless the D option was specified on the 
DLFP command. 

The general format of a log file listing is shown 
in figure 6-12. (Section 7 Includes a sample 
output.) NETON and NETOFF calls are logged to 
record the start and end of NAM interfacing; only 
successful NETON calls are logged. Each AIP call 
logged is followed by the octal relative address 
(in parentheses) from which the call was made. The 
NETON call log includes the parameter values 
declared on the statement. The NETDBG call log 
lists the value declared for dbugsup as OPTl and 
for dbugdat as 0PT2. Calls that transfer super¬ 
visory messages or blocks are logged with their 
declared parameters, followed by the block header 
contents and block text area contents. (All words 
comprising a supervisory message are listed.) The 
contents of each word are given in hexadecimal , 
octal , 6-bit display code form, and ASCII-coded 
form. Each block or message is numbered in the 
order it was transferred. 
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Keywordt Value Desc ription 

B Specifies that only upline blocks with the flow control break flag bit (bit brk) 

set in the application block header are output. 

yymmdd Specifies that only messages or blocks that were logged on or after this date 

are output. Messages or blocks before this date are not output, yy is the 
rightmost two digits of the year, mm is the month, and dd is the day of the 
month; 00£yyjC99, 01_<mm_<12, 0Kdd^31. 

hhmmss Specifies that only messages or blocks that were logged on or after this time 

are output. Messages or blocks before this time are not output. If the debug 
log file contains more than one day's traffic, messages or blocks beginning 
after the first occurrence of this time will be output if BD is not specified, 
hh is the hour, mm is the minute, and ss is the second; 00<hh<24, 0Q<mra<59, 
0q<ss<59. - - - 

C Specifies that only network data blocks with the cancel flag set in the appli¬ 

cation block header are output. 

(-N= n Specifies that only synchronous and asynchronous supervisory messages and net¬ 
work data blocks relating to connection number n are output; 1<n<255. 

DN= Reserved for CDC use. 

E Specifies that only supervisory messages with the error bit set are output. 

ED= yymmdd Specifies that messages or blocks on or after this date are not to be output. 

yy is the rightmost two digits of the year, mm is the month, and dd is the day 

of the month; 00£yy_<99, 0Kmm_<12, 0Kdd£31. 

hhmmss Specifies that messages or blocks on or after this time are not to be output. 

If the debug log file contains more than one day's traffic, searching terminates 
after the first occurrence of this time if ED is not specified, hh is the hour, 
ram is the minute, and ss is the second; 00^hh^2A, 00_<mm_<59, 00<ss_<59. 

l-E= n Specifies maximum length in central memory words of each message or block to be 

output; Kn_<410 (default=10). 

F Specifies that only network data blocks with the no format effector bit set in 

the application block header are output. 

N Specifies that only supervisory messages or network data blocks are output. 

Messages generated by applications for the debug log file are ignored. 

NM= n Specifies that only n messages or blocks are output; 0<1000000. 

P= Specifies that only network data blocks with the parity-error bit or auto input 

mode bit set in the application block header are output. 

PF= hh Specifies that only supervisory messages with the primary function code (PFC) 

equal to hh-]^ are output. No check is made to determine whether hh is a legal 
PFC value; OOKhh-i^FF. 

PS= hhxx Specifies that only supervisory messages with PFC/SFC equal to hhxxi^ are output. 

No check is made to determine whether hh is a legal PFC value and xx is a legal 
SFC value. OOOOjChhi6<FFFF. 

R ■ Specifies that only supervisory messages with the response bit set are output. 

SM= n r Specifies that no messages or blocks are output until the nth message, which . 

satisfies all the other keyword options, is found; O^n^lOOOOOO. 

SN= Reserved for CDC use. 

T -Specifies that only upline messages or blocks with the data truncation flag bit 

set in the application block header are output. 
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Keyword t Value Descriptio n 

U Specifies that only messages or blocks with the input block undeliverable bit 

set in the application block header are output. 

X Specifies that only messages or blocks with the transparent data bit set in the 

application block header are output. 


tThe same keyword can appear more than once in a directive record. If there is a value associated with 
this keyword, the value in the last occurrence of the keyword is the one used for the search. Blanks 
can precede or follow the = sign. If both PF and PS are'specified, the last one specified overrides the 
first one specified. If there are errors in the directive record, the job is aborted unless the D option 
was specified on the DLFP command. If the D option was specified, the directive record in error is 
ignored and processing restarts with the next directive record, if any. If there are multiple errors in 
a directive record, all errors are identified. 


Figure 6-10. DLFP Directive Keyword Format (Sheet 2 of 2) 


Example Explanation 

R,E DLFP processes and outputs all supervisory messages that have both 

the response and error bit set. There are currently no supervisory 
messages that have both bits set. 

BO=780229,BT=2401,ED=780228 DLFP does not process this directive record because it contains 

errors. The first error is that February 29, 1978 is an invalid date. 
The second error is that 2401 is an invalid time. Note that it was 
not an error to have the ED date earlier than the BD date although no 
messages would ever be processed because of it. 

PF=ABC,SH=-1,LE=1F,NH=10000000 DLFP does not process this directive record because it contains 

errors. The first error is that ABC is not a two-character hexa¬ 
decimal number. The second error is that - is not a legal character 
to have in the directive record. The third error is that IF is not a 
decimal number. The fourth error is that the character string 
NM=10000000 is greater than 10 characters. 

X,CN=15,SM=20 DLFP processes and outputs all network data blocks for connection 

number 15 that have the transparent bit set, except for the first 19. 

PS=8301,CN=5,PF=83 DLFP processes and outputs all supervisory messages relating to con¬ 

nection number 5 that have a PFC=83-|6(FC mnemonic). Note that even 
though PS is also specified, the directive is ignored because PF is 
specified after it. 

BC=781104,BT=2350,ED=781105, DLFP processes and outputs all messages and blocks that occurred from 

11:50 PM on November 4, 1978 to midnight. 

DLFP processes the first ten supervisory messages with PFC=67-|^CC0N 
mnemonic). Only the first two words of each supervisory message are 
output. 

DLFP outputs no messages. 81 is too large a value for SFC, so DLFP 
does not find any matching supervisory message. 

DLFP processes and outputs all CON/ACRQ/R supervisory messages re¬ 
lating to connection number 1 that have the error bit set. 

DLFP does not process this directive record because it contains 
errors. The first error is that the first keyword does not begin in 
column 1. The second error is that 300 is too large a connection 
number. The third error is that there should be a comma or blank 
between the U and X. Even if the three errors were not present, DLFP 
would not output any messages because currently FD is not a Legitimate 
PFC value. Also CN=30 does not fix the error in the first CN 
directive. 


Figure 6-11. DLFP Directive Examples 


ET=000000 

LE=2,PF=67,NH=10 

PS=8381 

PS=6302,CN=1,E 

,CN=300,UX,PF=FD,CN=30 
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aname LOG FILE OUTPUT 


current date yy/mm/dd 



DATE RECORDED yy/mm/dd 


PAGE ddd 

hh.mm.ss.mil 

NETON (oooooo) ANAME 

= ccccccc DATE = yy/mm/dd 


MSG NO. ddd 

NSUP ADDR = 000000 MINACN = dddd MAXACN = dddd 




hh.mm.ss.mil 

NETDBG (oooooo) OPTI 

= b 0PT2 = b DATE = 

yy/mm/dd 


MSG NO. ddd 

hh.mm.ss.mil 

NETGET (oooooo) ACN 

= dddd HA = oooooo TA 

= oooooo TLMAX 

= dddd 

MSG NO. ddd 

ABT = dd 

ADR = dddd ABN = oooooo ACT = dd STATUS = 

bbbbbbbb TLC = 

ddd 


001 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 

mnemonic 

002 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


nnn 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


hh.mm.ss.mil 

NETLOG (oooooo) 




MSG NO. ddd 

001 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 

mnemonic 

002 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


003 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

■cccccccccc 

aaaaaaaaa 


hh.mm.ss.mil 

NETGETL (oooooo) ALN 

= dddd HA = oooooo TA = oooooo TLMAX 

= dddd 

MSG NO. ddd 

ABT = dd 

ADR = dddd ABN = oooooo ACT = dd STATUS = 

bbbbbbbb TLC = 

ddd 


001 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 

mnemonic 

002 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


nnn 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


hh.mm.ss.mil 

NETGETF (oooooo) ACN 

= dddd HA = oooooo NA = dd TAA = oooooo 

MSG NO. ddd 

ABT = dd 

ADR = dddd ABN = oooooo ACT = dd STATUS = 

bbbbbbbb TLC = ddd 


FRAGMENT 

1 SIZE = dddd 

ADDRESS = oooooo 




001 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 

mnemonic 

002 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


FRAGMENT 

2 SIZE = dddd 

ADDRESS = oooooo 




FRAGMENT 

dd SIZE = dddd 

ADDRESS = oooooo 




nnn 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


hh.mm.s5.mil 

NETGTFL (oooooo) ALN 

= dddd HA = oooooo NA 

= dd TAA = oooooo 

MSG NO. ddd 

ABT = dd 

ADR = dddd ABN = oooooo ACT = dd STATUS = 

bbbbbbbb TLC = ddd 


FRAGMENT 

1 SIZE = dddd 

ADDRESS = oooooo 




001 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 

mnemonic 

FRAGMENT 

dd SIZE = dddd 

ADDRESS = oooooo 




nnn 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


hh.mm.5S.mil 

NETPUT (oooooo) HA = 

oooooo TA = oooooo 



MSG NO. ddd . 

ABT = dd 

ADR = dddd ABN = oooooo ACT = dd STATUS = 

bbbbbbbb TLC = ddd 


001 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 

mnemonic 

002 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa 


nnn 

hhhhhhhhhhhhhhh 

oooooooooooooooooooo 

cccccccccc 

aaaaaaaaa- 



Figure 6-12, General Format of DLFP Output (Sheet 1 of 2) 
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hh.mm.ss.mil 
ABT = dd 

NETPUTF (oooooo) HA = oooooo NA = dd TAA = oooooo 

ADR = dddd ABN = oooooo ACT = dd STATUS = bbbbbbbb TLC = ddd 

MSG NO. ddd 

FRAGMENT 

001 

1 SIZE = dddd ADDRESS = oooooo 

hhhhhhhhhhhhhhh oooooooooooooooooooo cccccccccc aaaaaaaaa 

mnemonic 

nnn 

■ hhhhhhhhhhhhhhh oooooooooooooooooooo cccccccccc aaaaaaaaa 


FRAGMENT 

nnn 

dd SIZE = dddd ADDRESS = oooooo 
hhhhhhhhhhhhhhh oooooooooooooooooooo cccccccccc aaaaaaaaa 


hh.mm.ss.mil 

NETOFF 

(oooooo) DATE = yy/mm/dd. 

MSG NO. ddd 

LEGEND: 




aname 


Application name. 


hh .mm.ss 

.mi 1 

System clock time of the AIP call in hours, minutes, seconds 

, and milliseconds. 

yy/ram/dd 


System date expressed as year, month, and day. 


mnemonic 


For supervisory messages, the message mnemonic appears; for 
area is blank. 

network data blocks, this 

a ... a 


Indicates ASCII characters are listed. 


b ... b 


Indicates binary digits are listed. 


c ... c 


Indicates display code characters are listed. 


d . • • d 


Indicates decimal digits are listed. 


h ... h 


Indicates hexadecimal digits are listed. 


0 • • • 0 


Indicates octal digits are listed. 


n ... n 


Indicates last central memory word listed from block. 



Figure 6-12. General Format of DLFP Output (Sheet 2 of 2) 


The listing provides the following labeled infor¬ 
mation : 

ACN gives the value used for the acn parameter 
in the indicated call. 

ALN gives the value used for the aln parameter 
in the indicated call. 

HA gives the octal relative address used in 
place of the symbolic address specified for the 
ha parameter in the indicated call. 

TA gives the relative address used in place of 
the symbolic address specified for the ta 
parameter in the indicated call. 

NA gives the value used for the na parameter in 
the indicated call. 

TAA gives the relative address used in place of 
the symbolic address specified for the taa 
parameter in the indicated call. 

TLMAX gives the value used for the tlmax 
parameter in the indicated call. 

ABT gives the abt field content for the appli¬ 
cation block header used in the indicated call. 


ADR gives the adr or acn field content for the 
application block header used in the indicated 
call. 

ABN gives the abn field content for the appli¬ 
cation block header used in the indicated call. 

ACT gives the act field content for the appli¬ 
cation block header used in the indicated call. 

STATUS gives the settings of bits 19 through 12 
for the application block header used in the 
indicated call, at the time the call is com¬ 
pleted . 

TLC gives the tic field content for the appli¬ 
cation block header used in the indicated call. 

FRAGMENT gives the number within the call taa 
array used to locate the corresponding infor¬ 
mation transferred by the call. 

SIZE gives the content of the size field within 
the call taa array used to delimit the corre¬ 
sponding information transferred by the call. 

ADDRESS gives the address field content of the 
taa array used to locate the corresponding 
information transferred by the call. 
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Statistical File and Associated Utilities 


The optional AIP code that creates the statistical 
file allows you to record cumulative figures of 
exchanges between the program and the network. The 
AIP utility routine NETSTC gives the program a 
method of selecting which portions of the program 
have figures accumulated. The AIP utility NETLGS 
allows you to write messages in the statistical 
file. All statistical output is written to a local 
file named ZZZZZSN. 

Whether or not the statistical file is created 
depends on the system library used to satisfy the 
application program's externals. AIP code for the 
program can be loaded from either NETIO or (if the 
installation elects to Install it) from NETIOD. 
When NETIOD is used, all code needed to create the 
statistical file is loaded; accumulation of figures 
is automatically turned on initially. Because this 
code causes additional processing overhead and 
central memory requirements for the application 
program's control point, you can remove the code 
when the statistical file is not needed. You can 
remove the code from the job without altering the 
application program's structure by loading the AIP 
code from NETIO instead of NETIOD. When NETIO is 
used, the only part of the statistical file code 
loaded is a do-nothing version of NETSTC. 

When NETIOD is used, the ' statistical file is auto¬ 
matically created without application program calls. 
You can use calls to NETSTC to switch accumulation 
off and back on throughout the program, and to dump 
and restart statistics counters. 


NETSTC Utility 

NETSTC calls use the same syntax and calling 
sequences as other AIP calls. (See sections 4 and 
5.) Figure 6-13 shows the NETSTC utility FORTRAN 
call statement. 


CALL NETSTC(onoff,avai L) 


onoff An input parameter that turns the 

accumulation of statistics on or off. 
This parameter can have the values; 

=0 Turn accumulation on. 

=1 Turn accumulation off. 

When statistics accumulation is turned 
on, each call to an AIP routine 
increments a counter for that routine 
and each block transferred between the 
application program and the network 
increments a counter for blocks of 
that type. Incrementing continues 
until a call with an onoff parameter 
of 1 is issued. Calls with onoff 
parameters of 0 cause the counters to 
be reset to 0. 

avail A return parameter that indicates 

whether the statistics accumulation 
portion of AIP was loaded when the 
program was loaded. On return from 
the call, this parameter can have the 
values: 

=0 Loading occurred from NETIOD 
and accumulation is possible. 

=1 Loading occurred from NETIO and 
accumulation is not possible. 

When a value of 1 is returned, 
specification of 0 for the onoff 
parameter has no effect but does not 
cause an error. 


Figure 6-13. NETSTC Utility FORTRAN 
Call Statement Format 


Calls to NETSTC can occur in programs using either 
NETIO or NETIOD. For example, when a NETSTC call 
turns accianulatlon on and a status is returned 
indicating accumulation is not possible, no error 
occurs and the option selection is ignored. When 
the program contains a NETSTC call immediately 
after NETON to turn accumulation off and a status 
is returned indicating accumulation is possible, a 
statistical file is still created to contain a 
record of the program's NETON, NETSTC, and NETOFF 
calls. A call to NETSTC before NETON is legal. 

Statistical file creation begins when the appli¬ 
cation program successfully completes its NETON 
call and ends when NETOFF is issued. A logical 
end-of-record is written to file ZZZZZSN when 
NETOFF is called. Because the output buffer used 
for the file is not completely emptied into the 
statistical file until the application program 
issues a NETOFF call, it is important to issue the 
call even when the program loses communication with 
the network; otherwise, the last few entries written 
to the statistical file for the job run cannot be 
saved. All statistics are written to file ZZZZZSN 
and the counters reset to zero whenever a call to 
NETSTC is made to turn statistics gathering off and 
AIP was loaded from NETIOD. Individual statistics 
are written to ZZZZZSN and reset to zero whenever 
the counter overflows. 


NETLGS Utility 

NETLGS calls use the same syntax and calling 
sequences as other AIP calls. (See sections 4 and 
5). Figure 6-14 shows the NETLGS utility FORTRAN 
call statement format. NETLGS allows an application 
to enter messages into the statistical log file 
ZZZZZSN. 


CALL NETLGS(address,size) 


address An input parameter that indicates the 
address of the message to be written 
to the statistics log file. The 
message must contain 6-bit display 
code information with a line termi¬ 
nator (12 to 66 bits of zero, right- 
justified in a central memory word). 

size An input parameter that indicates the 

number of words in the message. 


Figure 6-14. NETLGS Utility FORTRAN Call 
Statement Format 
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When application program execution ends, the 
statistical file exists as a local file named 
ZZZZZSN. The file is written using NOS data 
transfer macros; the contents are 6-bit display 
code characters, formatted for printer output. To 
obtain a listing of this file, the file must be 
rewound and copied to OUTPUT, or otherwise disposed 
by using ROUTE. 


Each period for which statistics are accumulated 
during program execution is listed separately in- 
the statistical file. Figure 6-15 shows the general 
format of the period listings. The counters used 
are 60-bit signed integers, reset to zero at the 
beginning of each period. If a counter is not used 
during a given period (its value remains zero), the 
corresponding line for the counter is omitted from 
the listing for that period. If a counter over¬ 
flows during a given period, the corresponding line 
in the listing is preceded by the message: 


****COUNTER OVERFLOW**** 


and the counter is reset to zero. If the program 
is running in parallel mode during the period, the 
number of transfer attempts unsuccessful because 
NIP was busy are listed. The CPU utilization shown 
is cumulative between the NETON and NETOFF calls. 
The NAK-S line indicates the number of block-not- 
delivered (FC/NAK/R) supervisory messages received. 


DEPENDENCIES FOR PROGRAM USE 

If an application program needs to use any of the 
features described in Types of Application Programs 
earlier in this section, the application program 
should be identified in the network's files as part 
of the local host computer system's resources. 
This is done by entering its application program 
name into the local configuration file, using the 
Network Definition Language (NDL). This action is 
not the application programmer's responsibility and 
is not described in this manual. Use of the Net¬ 
work Definition Language is described in the Network 
Definition Language reference manual mentioned in 
the preface. 

Until the application program is identified in the 
NOS system COMTNAP common deck, the program cannot 
call NETON and execute with actual logical connec¬ 
tions made. Until configured as a network resource, 
the program's connection-servicing logic cannot be 
debugged. 

When the program is identified in COMTNAP, it can 
successfully perform a NETON call if the network is 
operational. As soon as a NETON call is completed, 
terminals can request connection to the program. 


NAM STATISTICS 

GATHERING STARTED 

- {^^c} 

DATE yy/mm/dd. TIME hh.mm.ss. 

NAH STATISTICS 

GATHERING TERMINATED 

- 

DATE yy/mm/dd. TIME hh.mm.ss. 

CPU TINE USED: 

dddddd SEC 

NUMBER OF PROCEDURE CALLS 

NETCHEK 

dddddd 

NETGET 

dddddd 

NETGETF 

dddddd 

NETGETL 

dddddd 

NETGTFL 

dddddd 

NETPUT 

dddddd 

NETPUTF 

dddddd 

NETSETP 

dddddd 

NETWAIT 

dddddd 

NUMBER OF WORKLIST TRANSFER ATTEMPTS 

SUCCESSFUL 

dddddd 

UNSUCCESSFUL dddddd 

NUMBER OF INPUT/OUTPUT BLOCKS TRANSFERRED 

INPUT 

ABT=0 dddddd 

INPUT 

ABT=1 dddddd 

INPUT 

ABT=2 dddddd 

INPUT 

ABT=3 dddddd 

OUTPUT 

ABT=1 dddddd 

OUTPUT 

ABT=2 dddddd 

OUTPUT 

ABT=3 dddddd 

NUMBER OF ERRORS 

LOGICAL ERROR dddddd 

NAK-S 

dddddd 

Legend: 


yy/mm/dd 

System date of the call begin¬ 
ning or ending the accumulation 
period, expressed as year, 
month, and day 

hh»inn).ss 

System clock time of the call 
beginning or ending the accumu¬ 
lation period, expressed in 
hours, minutes, and seconds 

d...d 

Indicates decimal digits 


Figure 6-15. General Format of One Period 
Listing in Statistical File 
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Before a terminal can complete a connection to the 
program, the user name from its login procedure 
must have an access word bit associated with the 
application program's name in COHTNAP. This 
association is established by using MODVAL and must 
exist for all login user names. The procedure is 
not described further in this manual because it is 
not the application programmer's responsibility. 


If the application program uses the batch device 
Interface, the owning console for the passive 
device it is intended to service must be configured 
in the local configuration file with the program 
declared as the primary application for the ter¬ 
minal. Unless this is done, the passive devices 
cannot access the application program. The appli¬ 
cation programs released by CDC with this version 
of the network software only provide a mechanism 


for the switching of console device connections to 
other programs. A passive device configured with 
the Remote Batch Facility as its primary application 
program cannot be used by any other application 
program. 


MEMORY REQUIREMENTS 

Although the size of an application program varies 
with its complexity and functions, the AIP coding 
added by the CYBER loader does not normally exceed 
1100 words of central memory. The version of AIP 
that generates the debug log file and statistics 
file requires 1100 more words. Using the QTRM 
utility package adds less than 700 additional words 
to the program's central memory field length 
requirements. 
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SAMPLE FORTRAN PROGRAM 


7 


This section contains an annotated listing of 
sample FORTRAN program RMV3, the debug log file, 
and statistics file generated when the program is 
run, and the configuration information used so that 
the program could be run. In this sample program, 
RMV3 is used to refer to the name of the FORTRAN 
program and the name of the batch job that ran it, 
while RMV2 is used to refer to the application 
name. This sample program does not attempt to use 
all possible supervisory message sequences or other 
features of the Network Access Method Interface to 
the network software. 

Application program RMV2 echoes terminal keyboard 
input back to the terminal and provides some addi¬ 
tional dialog. Possible dialogs are described later 
in this section. 


CONFIGURATION REQUIREMENTS 

RMV2 is designed only for the servicing of inter¬ 
active console devices. This program contains no 
logic to Initialize batch device connections or to 
support appllcation-to-application connections. 
RMV2 contains no logic requiring it to be config¬ 
ured as a unique identifier application program. 
RMV2 is not configured as a privileged application; 
it is submitted to the operating system and executed 
as a batch origin job. 

RMV2 is completely configured in the local config¬ 
uration file by the Network Definition Language 
statement: 

RMV2:APPL. 

and terminal operators must log in to it using this 
application program name. 

Devices accessing RMV2 can be configured with RMV2 
as an initial application program if they have a 
device type of console. 


JOB COMMAND PORTION 

Program RMV3 was run using the job commands shown 
in figure 7-1. The user name appearing on the NOS 
USER command has the CUCP bit set in its associated 
access word. 

Although the command portion uses the version of AIP 
that generates the debugging and statistical files, 
RMV3 itself does not contain calls to the routines 
controlling entries in those files. The files are 
generated for the entire program by default. 


PROGRAM PORTION 

Figure 7-2 shows the program portion of the RMV3 
batch job. The comments in the program explain most 
of the program's logic. The terminal operator 
dialog supported by RMV2 Includes the text exchanges 
shown in figure 7-3. This figure does not illus¬ 
trate login dialog or dialog after RMV2 is discon¬ 
nected from the device. The former can be inferred 
from the connection-request information entered for 
the connection in the debugging log file created by 
the AIP code after NETON of RMV2. Note that RMV2 
responds to most error conditions or problems by 
shutting down. 


PROGRAM OUTPUT 

The FORTRAN code in RMV3 produces several entries 
in file OUTPUT. Figure 7-4 shows the debug log 
file listing produced by the AIP code in RMV3. The 
message traffic listed in this file can be compared 
with the program logic documented in figure 7-2 to 
produce a processing flow diagram for the connection 
involved. Figure 7-5 shows the statistical file 
listing produced by the AIP code in RMV3. 


RMV3. <-Job name command. 

USER(APPL1,PASS,FAM1) 


CHARGE(0059,2934657) 

ATTACH(RMV) 

FTN5 (I=RMV,L0=S/-A) 

LDSET(LIB=NETI0D) <-,-Uses debug and statistical file optional code version of AIP. 

GET(RELJ.OB) <-File containing NOS commands for NETREL call. 

L60. 


Disposes of local files containing statistical file and debug log file 
by copying the first one to OUTPUT and executing the postprocessor to 
completely list the contents of the second one. 


REWIND(ZZZZZSN) 
DLFP(I=0) 

COPY(ZZZZZSN) 


Figure 7-1. Command Portion of RnV3 Job 
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PROGRAM RMV3 74/74 OPT=0,ROUND= A/ S/ M/-D,-OS FTN 5.1+599 83/08/05. 11.38.17 PAGE 1 

0O=-LONG/-OT,ARG=-COMMON/-FIXED,CS= USER/-FIXED,DB=-TB/-SB/-SL/ ER/-ID/-PMD/-ST,PL=5000 
FTN5,I=RMV,L=0UTPUT,L0=S/-A. 


1 PROGRAM RMV3 


C NAM 1 REFERENCE MANUAL SAMPLE PROGRAM 
C ECHOS INTERACTIVE CONSOLE OPERATOR INPUT 

C NOTE THAT THE DEBUG LOG FILE AND STATISTICAL FILE LOCAL NAMES 
C ARE NOT REQUIRED ON THE PROGRAM STATEMENT GIVEN ABOVE. 


IMPLICIT INTEGER(A-Z) 

COMMON /RMCOM/K(20),LASTBLK,I,S,NSUP,SHH0R,0SHDR,DSHDR1,NACN(20) 
COMMON /RHCOH/CONEND,ROMARK,ACN,ABN(20),SH(20),ABL(20),ABHIBU,US 
COMMON /RMCOM/NB(20),HA,INSTAK(20),OUTSTAK(20),ENDCN,SHUTD,INTRRSP 
COMMON /RMCOH/INTRCHR,CHANRST,CHANCLR 

C NOTE THAT THE TEXT AREAS ARE SEPARATE FOR DATA AND SUPERVISORY 
C MESSAGES. THEIR SIZES ARE CHOSEN FOR THE LARGEST EXPECTED SUPERVISORY 
C MESSAGE,ARBITRARILY SUPPORTING UP TO 314 CHARACTERS OF DEVICE 
C INPUT DATA. 


COMMON /RMCOH/TA(63),STAK(20),OVRFLHA(8,20),OVRFLTA(63,8,20),US1 
COMMON /RHCOM/IABN(20),SMHA,SMTA(63),SSH(8),MC,LFN,ABT,ACT,TLC 
EXTERNAL REPREV,CHKSUM 


C INITIALIZE AND SET CONSTANTS 
C SET UP LOCAL FILE NAME FOR NETREL CALLS 
DATA LFN/L"RELJOB"/ 

C FILE RELJOB CONTAINS THE FOLLOWING COMMANDS: 

C RELJOB. 

C USER(APPL1,PASS,FAH1) 

C CHARGE(0059,2934657) 

C DLFP(I=0) 

C THIS IS THE CIRCULAR OUTPUT STACK FOR EACH CONNECTION 
DATA INSTAK, OUTSTAK/20*0,20*0/ 


C K IS THE APPLICATION BLOCK NUMBER COUNTER 
DATA K/20*1/ 


C THESE ARE NSUP WORD FIELD MASKS 

DATA s/0"020000000000a0000000'7 
DATA I/0"04000000000000000000"/ 
DATA Mc/O"00000000007777777777'7 


Figure 7-2. Program Portion of RMV3 (Sheet 1 of 24) 
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PROGRAM RMV3 74/74 OPT=0,ROUND= A/ S/ M/-0,-DS FTN 5.1+599 83/08/05. 11.38.17 


56 

57 

58 C THESE ARE BREAK-PROCESSING FLAGS 

59 

60 DATA INTRCHR,CHANRST,CHANCLR/0,0,0/ 

61 
62 

63 C THIS INITIALIZES THE FLOW CONTROL ALGORITHM FOR ALL 

64 C POSSIBLE CONNECTIONS 

65 

66 DATA ABL,NB,NACN,ACN,ABHIBU,STAK/20*0,20*0,20*0,0,0,20*0/ 

67 

68 

69 C PACK MASK FOR CHARACTERS THAT COMPRISE OPERATOR END-CONNECTION 

70 C COMMAND FOR NORMAL DISCONNECTION PROCESSING 

71 C WHICH IS THE CAPITALIZED COMMAND ENDCN IN 12-BIT BYTES 

72 

73 DATA ENDCN/0"01 050116010401030116"/ 

74 

75 

76 C PACK MASK FOR CHARACTERS THAT COMPRISE OPERATOR SHUTDOWN 

77 C COMMAND FOR NORMAL PROGRAM TERMINATION PROCESSING, 

78 C WHICH IS THE CAPITALIZED COMMAND SHUTD IN 12-BIT BYTES 

79 

80 DATA SHUTD/0"01230110012501240104"/ 

81 
82 

83 C PACK A CONSTANT FOR SUPERVISORY MESSAGE HEADER WORDS 

84 

85 DATA SMHOR/0"03000000000004000001"/ 

86 

87 

88 C PACK A CONSTANT HEADER WORD FOR DISPLAY CODED OUTPUT 

89 C OF BLOCK TYPE 2. NOTE THAT THE NO-FORMAT-EFFECTOR BIT IS NOT SET 

90 C BECAUSE ALL OUTPUT TO THE DEVICE GENERATED BY THE PROGRAM CONTAINS 

91 C A FORMAT EFFECTOR CHARACTER. 

92 

93 DATA DSHDR/0"02000000000020000024"/ 

94 

95 

96 C NOTE THAT ONLY 10 CHARACTERS OF OUTPUT ARE PERMITTED BY 

97 C THE TLC DECLARED, PLUS A ZERO TERMINATOR WORD FOR THE LOGICAL LINE. 

98 

99 C PACK A CONSTANT HEADER WORD FOR DISPLAY CODED OUTPUT 

100 C OF BLOCK TYPE 1. NOTE THAT THE NO-FORHAT-EFFECTOR BIT IS NOT SET 

101 C BECAUSE ALL OUTPUT TO THE DEVICE GENERATED BY THE PROGRAM CONTAINS 

102 C A FORMAT EFFECTOR CHARACTER. 

103 

104 DATA DSHDR1/0"01000000000020000024"/ 

105 

106 C AGAIN, ONLY 10 CHARACTERS ARE PERMITTED, PLUS A TERMINATOR WORD. 

107 

108 

109 C CREATE MASK FOR UNIT SEPARATOR INSERTION CODE 

110 

111 DATA US,US1/O"00370000000000000000",0"70370000000000000000"/ 

112 


Figure 7-2. Program Portion of RMV3 (Sheet 2 of 24) 
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PROGRAM RMV3 74/74 0PT=0,R0UND= A/ S/ M/-D,-0S FTN 5.1+599 

83/08/05. 11.38.17 PAGE 3 


113 





114 

C 

SET UP REPRIEVAL CODE TO SALVAGE DEBUG AND STATISTICAL FILES 


115 





116 


CALL REC0VR(REPREV,0"277",L0CF(CHKSUM)) 



117 





118 





119 

C 

SET UP ALL OTHER VARIABLES AND CONSTANTS 



120 





121 


CALL SETUP 



122 





123 





124 

C 

ESTABLISH ACCESS TO THE NETWORK AND BEGIN DEBUG LOG 



125 

C 

FILE CREATION 



126 





127 


CALL NET0N("RHV2",NSUP,NSTAT,1,20) 



128 





129 





130 

C 

TEST FOR ACCESS COMPLETION 



131 





132 


IF (NSTAT.NE.O) THEN 


1 

133 


PRINT 100, NSTAT 


1 

134 


100 FORMAT (' NSTAT = ’,020) 


1 

135 


STOP 111 


1 

136 


END IF 


1 

137 




1 

138 




1 

139 

C 

UPDATE NSUP FLAGS, THEN PERFORM CONNECTION ESTABLISHMENT 

PROCESSING 

1 

140 

C 

AND DISPOSE OF OTHER SUPERVISORY MESSAGES RECEIVED. 


1 

141 





142 


15 CALL NETWAIT (4095,0) 

1 


143 


16 SHUTDWN=0 



144 


SYNC=0 



145 


CALL LOOKSM (SHUTDUN,L,SYNC) 



146 





147 





148 

c 

RETURN FROM FC/ACK/R 



149 





150 


17 IF (L.EO.D THEN 


1 

151 


GO TO 9 


1 

152 




1 

153 




1 

154 

c 

RETURN FROM CON/REQ/R 


1 

155 




1 

156 


ELSE IF (L.EQ.2) THEN 


1 

157 


GO TO 15 


1 

158 




1 

159 




1 

160 

c 

RETURN FROM FC/INIT/R 


1 

161 




1 

162 


ELSE IF (L.EQ.3) THEN 


1 

163 


GO TO 41 


1 

164 




1 

165 




1 

166 

c 

RETURN FROM INTR/USR/R 


1 

167 




1 

168 


ELSE IF (L.Ea.4) THEN 


1 

169 


IF(INTRCHR.EQ.O) THEN 



Figure 7-2. Program Portion of RMV3 (Sheet 3 of 24) 
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2 

170 

GO TO 9 


2 

171 

ELSE 


2 

172 

GO TO 551 


2 

173 

END IF 


2 

174 



2 

175 



2 

176 

C RETURN FROM FC/INA/R 


2 

177 



1 

178 

ELSE IF CL.Ea.5) THEN 


1 

179 

GO TO 9 


1 

180 



1 

181 



1 

182 

C RETURN FROM CON/CB/R 


1 

183 



1 

184 

ELSE IF <L.EQ.6) THEN 


1 

185 

GO TO 9 


1 

186 



1 

187 



1 

188 

C RETURN FROM FC/NAK/R 


1 

189 



1 

190 

ELSE IF (L.Ea.7) THEN 


1 

191 

GO TO 9 


1 

192 



1 

193 



1 

194 

C RETURN FROM ERR/LGL/R 


1 

195 



1 

196 

ELSE IF (L.Ea.8) THEN 


1 

197 

GO TO 9 


1 

198 



1 

199 



1 

200 

C RETURN FROM HOP/XX/R 


1 

201 



1 

202 

ELSE IF (L.Ea.9) THEN 


1 

203 

GO TO 9 


1 

204 



1 

205 



1 

206 

C RETURN FROM CON/END/R 


1 

207 



1 

208 

ELSE IF (L.Ea.10) THEN 


1 

209 

GO TO 9 


1 

210 



1 

211 



1 

212 

C RETURN FROM SHU/INS/R 


1 

213 



1 

214 

ELSE IF (L.Ea.11) THEN 


1 

215 

GO TO 554 


1 

216 



1 

217 



1 

218 

C RETURN FROM BI/MARK/R 


1 

219 



1 

220 

ELSE IF (L.EG.12) THEN 


1 

221 

GO TO 551 


1 

222 



1 

223 



1 

224 

C RETURN FROM BAD BLOCK 


1 

225 



1 

226 

ELSE 



Figure 7-2. Program Portion of RMV3 (Sheet 4 of 24) 
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1 227 

1 228 
1 229 

1 230 

1 231 

1 232 


GO TO 777 
END IF 


C INITIALIZE CONNECTION BY SENDING OUTPUT 


41 LASTBLK=1 


C SEND IDENTIFYING BANNER AS FIRST OUTPUT AFTER INITIAL CONNECTION 

SENDAI 

HA=DSHDR1 

CALL NSTORE(HA,L"ABHADR",ACN) 

TA(1)="1RMV2 VER3" 

TAC2)=0 

CALL OUTPT (SEND) 


1 255 

1 256 

1 257 

1 258 

1 259 

1 260 
1 261 
1 262 
1 263 

1 264 

265 

266 

267 

268 

269 

1 270 

1 271 

1 272 

1 273 


1 278 

1 279 

1 280 
1 281 
1 282 
1 283 


C NOTE THAT ALL CONNECTIONS ARE SERVICED AS FULL-DUPLEX ON THE 
C APPLICATION PROGRAM'S END 

40 CALL PROMPT (SEND) 

LASTBLK=0 

39 CALL OUTPT (SEND) 

IF (SEND .EQ. 0) GO TO 38 
IF (STAK(ACN) .EQ. 1) THEN 
SEND=0 
GO TO 39 

ELSE IF (LASTBLK.EQ.1) THEN 
GO TO 40 
ELSE 

GO TO 9 
END IF 


C PAUSE TO ALLOW OUTPUT QUEUE TO CLEAR 

38 CALL NETWAIT(2,1) 

SHUTDWN=0 

SYNC=0 

CALL LOOKSM (SHUTDWN,L,SYNC) 

IF (L.EQ.1) THEN 
SEND=0 
GO TO 39 

ELSE IF (L.EQ.2) THEN 
IF(INTRCHR.EQ.O) THEN 
GO TO 9 
ELSE 

GO TO 551 
END IF 

ELSE IF (L.EQ.3) THEN 
GO TO 41 

ELSE IF (L.EQ.4) THEN 
GO TO 38 

ELSE IF (L.EQ.5) THEN 
GO TO 9 
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1 

284 

ELSE IF (L.EQ.6) THEN 

1 

285 

GO TO 15 

1 

286 

ELSE IF (L.EQ.7) THEN 

1 

287 

GO TO 9 

1 

288 

ELSE IF (L.EQ.8) THEN 

1 

289 

GO TO 9 

1 

290 

ELSE IF (L.EQ.9) THEN 

1 

291 

GO TO 9 

1 

292 

ELSE IF (L.EQ.10) THEN 

1 

293 

GO TO 15 

1 

294 

ELSE IF (L.EQ.11) THEN 

1 

295 

GO TO 554 

1 

296 

ELSE IF {L.EQ.12) THEN 

1 

297 

GO TO 551 

1 

298 

ELSE 

1 

299 

GO TO 38 

1 

300 

END IF 

1 

301 


1 

302 


1 

303 

C PAUSE FOR INPUT DATA OR A SUPERVISORY MESSAGE 

1 

304 



305 

9 CALL NETHAIT(4095,0) 


306 



307 



308 

C TEST FOR QUEUED MESSAGES OR DATA BLOCKS 


309 



310 

777 IF((NSUP.AND.S).NE.O) GO TO 16 


311 



312 



313 

C FETCH QUEUED INPUT FROM A DEVICE 


314 



315 

ALN=1 


316 

CALL NETGETL<ALN,HA,TA,10) 


317 



318 



319 

C UNPACK THE BLOCK HEADER FOR THE DELIVERED INPUT BLOCK 


320 



321 

778 ABT=NFETCH(HA,L"ABHABT"> 


322 

ACT=NFETCH(HA,L"ABHACT") 


323 

ACN=NFETCH(HA,L"ABHADR") 


324 

ABHXPT=NFETCH(HA,L"ABHXPT") 


325 

ABHTRU=NFETCH(HA,L”ABHTRU") 


326 

ABHCAN=NFETCH(HA,L"ABHCAN") 


327 

ABHIBU=NFETCH(HA,L"ABHIBU") 


328 

TLC=NFETCH (HA,L"ABHTLC") 


329 



330 



331 

C BRANCH TO PROCESS DATA BLOCK OR SYNCHRONOUS SUPERVISORY MESSAGE 


332 



333 

IF (ABT.EQ.3) THEN 

1 

334 

SYNC=1 

1 

335 

CALL LOOKSM (SHUTDWN,L,SYNC) 

1 

336 

GO TO 17 

1 

337 

END IF 

1 

338 


1 

339 


1 

340 

C MAKE ANOTHER ATTEMPT TO FETCH QUEUED BLOCK 
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1 341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 
1 375 

1 376 

1 377 

1 378 

1 379 

1 380 

1 381 

1 382 

1 383 

1 384 

1 385 

1 386 

1 387 

1 388 

1 389 

1 390 


IF (A0T.EQ.O.ANO.ABHIBU.EQ.1) CALL NETGET(ACN,HA,TA,63) 
IF (ABT.EQ.O.AND.ABHIBU.EQ.I) GO TO 778 
IF (ABT.EQ.0.AN0.ABHIBU.NE.1) GO TO 9 


C TEST FOR THROW-AWAY INPUT 


IF(ABHCAN.EQ.I) GO TO 40 


C TEST FOR TYPE-IN OF ENOCH COMMAND 


IF(TA{1).EQ.ENOCH) GO TO 444 


C TEST FOR TYPE-IN OF SHUTO COMMAND 


IFCTAd ).Ea.SHUTO) GO TO 666 


C PROCESS ECHOABLE TEXT 

CALL PACK (SEND) 
GO TO 39 


C PROCESS USER BREAKS 


551 IF((CHANCLR.EQ.1).AND.(CHAMRST.EQ.1)) THEN, 


C TELL THE DEVICE OPERATOR WHAT HAPPENED 

IF (INTRCHR.EQ.3) TA(1)=" BREAK 1 
IF (INTRCHR.EQ.4) TA(1)=" BREAK 2 
HA=DSHDR1 
TA(2)=0 

CALL NSTORE(HA,L"ABHADR",ACN) 

LASTBLK=1 

SEND=1 

CALL OUTPT(SEND) 
CHANCLR=CHANRST=INTRCHR=0 
GO TO 40 
ELSE 

GO TO 9 
END IF 


C DISCONNECT THIS TERMINAL DEVICE 


444 SMTACI )=SMTA(2)=0 

CALL NSTORE(SHTA,L''PFCSFC",CONEND) 
CALL NST0RE<SMTA,L"RC",0) 


C PASS CONNECTION DIRECTLY TO lAF WITHOUT DIALOG 
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398 



399 


CALL NST0RE(SHTA,L"C0NANM",R"IAF ") 

400 


SMHA=SHH0R + 0"1 " 

401 


CALL NST0RE(SMTA,L"C0NACN",ACN) 

402 


NACN(ACN)=0 

403 


CALL NETPUT(SMHA,SHTA) 

404 


GO TO 9 

405 



406 

666 

CALL SHUTON 

407 



408 



409 

554 

STOP 

410 


END 
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00=-L0NG/- 

OT,ARG=-COMHON/-FIXED,CS= USER/-FIXED,DB=-TB/-SB/-SL/ ER/-ID/-P«D/-ST,PL=5000 


FTN5,I=RMV 

,L=0UTPUT,L0=S/-A. 


1 

2 

SUBROUTINE LOOKSM CSHUTDWN,L,SYNC) 

1 


3 

4 

C PROCESS INCOMING SUPERVISORY MESSAGES 


5 

6 

IMPLICIT INTEGER (A-Z) 


7 

COMMON /RMCOM/K (20),LASTBLK,I,S,NSUP,SMHDR,DSHOR,DSHDR1,NACN(20) 


8 

COMMON /RMCOM/CONEND,ROMARK,ACN,ABN(20),SN(20),ABL(20),ABHIBU,US 


9 

COMMON /RHC0H/NBC20),HA,INSTAK(20),0UTSTAK(20),ENDCN,SHUTD,INTRRSP 


10 

COMMON /RHCOM/INTRCHR,CHANRST,CHANCLR 


11 

COMMON /RMCOM/TA(63),STAK(20),0VRFLHA(8,20),OVRFLTA(63,8,20),US1 


12 

COMMON /RMC0H/IABN(20),SMHA,SMTAC63),SSM(8),MC,LFN,ABT,ACT,TLC 


13 



14 



15 

C PROCESS SYNCHRONOUS SUPERVISORY MESSAGES 


16 



17 

IF (SYNC.EO.I) THEN 

1 

18 

SMHA=HA 

1 

19 

DO 2 1=1,63 

1 

20 

SMTA(I)=TA(I) 

1 

21 

2 CONTINUE 

1 

22 

GO TO 1 

1 

23 


1 

24 

ELSE 

1 

25 

GO TO 3 

1 

26 


1 

27 

END IF 

1 

28 


1 

29 


1 

30 

C WAIT FOR AN ASYNCHRONOUS SUPERVISORY MESSAGE IF NECESSARY 

1 

31 



32 

3 IF ((NSUP.AND.S).EQ.O) THEN 

1 

33 

IF(((NSUP.AND.I).EQ.O).AND.(SHUTDWN.EQ.O)) THEN 

2 

34 

CALL NETWAIT(4095,0) 

2 

35 


2 

36 

C RETURN TO FETCH INPUT DATA 

2 

37 


2 

38 

RETURN 

2 

39 


2 

40 

ELSE 

2 

41 

L=13 

2 

42 

RETURN 

2 

43 


2 

44 

END IF 

1 

45 

END IF 

1 

46 


1 

47 


1 

48 

C FETCH AN ASYNCHRONOUS SUPERVISORY MESSAGE FROM ACN=0 

1 

49 

C ON LIST ZERO 

1 

50 



51 

ALN=0 


52 

CALL NETGETL(ALN,SMHA,SMTA,63) 


53 



54 



55 

C UNPACK THE MESSAGE IDENTIFICATION AND BRANCH ON THE TYPE 
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56 

57 

58 

59 

60 
61 


62 

63 

64 

1 65 

1 66 

1 67 

1 68 

1 69 

1 70 

1 71 

1 72 

1 73 

1 74 

1 75 

1 76 

1 77 

1 78 

1 79 

1 80 

1 81 

1 82 

1 83 

1 84 

1 85 

1 86 

1 87 

1 88 

1 89 

1 90 

1 91 

1 92 

1 93 

1 94 

1 95 

1 96 

1 97 

1 98 

1 99 

1 100 

1 101 

1 102 

1 103 

1 104 

1 105 

1 106 

1 107 

1 108 

1 109 

1 110 

1 111 

1 112 


1 PFCSFC=NFETCHCSHTA,L"PFCSFC") 
PFC=NFETCH(SMTA,L"PFC") 


C NOTE THAT THIS CODE EXITS WITH THE L VALUE SET SO THAT IT CAN BE 
C USED FOR BRANCHING IN THE MAIN PROGRAM ON RETURN FROM LOOKSM 

IF (PFCSFC.EO.SMCI)) THEN 
L=1 

GO TO 10 

ELSE IF (PFCSFC.Ea.SM(2)) THEN 
L=2 

GO TO 20 

ELSE IF {PFCSFC.EQ.SM(3)) THEN 
L=3 

GO TO 30 

ELSE IF (PFCSFC.Ea.SM(4)) THEN 
L=4 

60 TO 50 

ELSE IF (PFCSFC.Ea.SMCS)) THEN 
L=5 

GO TO 60 

ELSE IF (PFCSFC.Ea.SM(6)) THEN 
L=6 

GO TO 70 

ELSE IF (PFCSFC.Ea.SM(7)) THEN 
L=7 

GO TO 80 

ELSE IF (PFCSFC.Ea.SM{8)) THEN 
GO TO 90 

ELSE IF (PFCSFC.Ea.SN<9)) THEN 
L=9 

00 9 M=1,7 

IF (PFCSFC. Ea. SSMCM) )GOTO (11,21,31,41,51,61,71) ,M 
9 CONTINUE 

ELSE IF (PFCSFC.EO.SMCIO)) THEN 
L=10 

GO TO 110 

ELSE IF (PFCSFC.Ea.SMCID) THEN 
L=11 

GO TO 120 

ELSE IF (PFCSFC. Ea.SHd 2)) THEN 
L=12 

GO TO 130 


C TEST FOR END OF MESSAGE BRANCHING TABLE 

ELSE 
L=13 
END IF 


C PROCESS UNRECOGNIZED SUPERVISORY MESSAGE CODE 
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113 IF CSn(L).EQ.999) THEN 

114 

115 C ISSUE DIAGNOSTIC MESSAGE TO OUTPUT FILE 

116 

1 117 PRINT 1000, SMHA,SHTA 

1 118 1000 FORMAT (' COULD NOT FIND SM IN TABLE OF SUPPORTED CODES', 

1 119 * //' HA = ',020,/' TA = ',/63(1X,O20/)) 

1 120 

1 121 END IF 

1 122 
1 123 

1 124 C TRY AGAIN 

1 125 

126 GO TO 3 

127 

128 

129 C PROCESS FC/ACK/R SUPERVISORY MESSAGE 

130 

131 10 ACN=NFETCH(SMTA,L"FCACN") 

132 IA8N(ACN)=NFETCHCSHTA,L"FCABN") 

133 

134 C UPDATE FLOW CONTROL ALGORITHM 

135 

136 NB(ACN)=NB(ACN) - 1 

137 RETURN 

138 

139 

140 C PROCESS CON/REQ/R SUPERVISORY MESSAGE 

141 

142 C UNPACK MESSAGE AND USE CONTENTS TO SET UP CONNECTION - 

143 C FLOW CONTROL ALGORITHM 

144 

145 20 ACN=NFETCH(SMTA,L"CONACN") 

146 ABLCACN)=NFETCHCSMTA,L"CONABL") 

147 DT=NFETCH(SMTA,L"CONOT") 

148 NB(ACN)=0 

149 

150 C PACK CON/REQ/N OR CON/REQ/A MESSAGE 

151 

152 SMTA(1)=0 

153 CALL NSTORE(SMTA,L"PFCSFC",L’!CONREQ") 

154 CALL NSTORE(SMTA,L"CONACN",ACN) 

155 

156 C SET RESPONSE BIT TO ACCEPT OR REJECT CONNECTION 

157 

158 IF (DT.EQ.O) CALL NSTORE (SMTA,L"RB",1) 

159 IF (DT.NE.O) CALL NSTORE (SMTA,L"EB",1) 

160 

161 C INPUT MUST BE ASCII IN 12-BIT BYTES 

162 

163 CALL NSTORE(SMTA,L"C0NACT",3) 

164 

165 C ASSIGN ALL INTERACTIVE CONSOLES TO LIST 1 

166 

167 CALL NSTORE(SHTA,L"C0NALN",1) 

168 SMHA=SMHDR 

169 
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170 

C SEND THE CONNECTION-ACCEPTED OR CONNECTION-REJECTED SUPERVISORY MESSAGE 


171 



172 

CALL NETPUT(SMHA,SMTA) 


173 



174 

RETURN 


175 



176 



177 

C PROCESS FC/INIT/R SUPERVISORY MESSAGE 


178 



179 

C SET THE RESPONSE BIT TO INDICATE READY FOR 


180 

C TRANSMISSION TO BEGIN 


181 



182 

30 CALL NST0RE(SMTA,L"RB",1) 


183 



184 

C DETERMINE LOGICAL CONNECTION INVOLVED AND UPDATE 


185 

C CONNECTION TABLE 


186 



187 

ACN=NFETCH(SHTA,L"FCACN") 


188 

NACN<ACN)=1 


189 

SMHA=SMHDR 


190 

IABN(ACN)=ABN(ACN)=0 


191 



192 

C SEND THE CONNECTION-INITIALIZED MESSAGE 


193 



194 

CALL NETPUT(SMHA,SMTA) 


195 



196 

RETURN 


197 



198 



199 

C PROCESS INTR/USR/R SUPERVISORY MESSAGE 


200 



201 

50 ACN=NFETCH(SMTA,L"INTRACN") 


202 

INTRCHR=NFETCH(SMTA,L"INTRCHR") 


203 



204 

C PACK RESPONSE MESSAGE AND CLEAR FLOW CONTROL PARAMETERS 


205 



206 

SMTA(1)=0 


207 

SMHA=SMHDR 


208 

CALL NSTORE CSHTA,L"PFCSFC",INTRRSP) 


209 

CALL NSTORE CSMTA,L"INTRACN",ACN) 


210 

CALL NETPUT (SMHA,SMTA) 


211 



212 

C IF THIS IS A USER BREAK, CLEAR THE OUTPUT QUEUE 


213 



214 

IF <(INTRCHR.EQ.3).0R.(INTRCHR.EQ.4)) THEN 

1 

215 

CHANRST=1 

1 

216 

INSTAK(ACN)=OUTSTAK(ACN)=STAK(ACN)=0 

1 

217 


1 

218 

END IF 

1 

219 


1 

220 


1 

221 

C TELL THE DEVICE OPERATOR WHAT HAPPENED 

1 

222 



223 

IF C(INTRCHR.NE.3).AND.(INTRCHR.NE.4)) THEN 

1 

224 

TA(1)=" BYPASSED " 

1 

225 

HA=DSHDR1 

1 

226 

TA(2)=0 
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1 

227 


CALL NSTORE(HA,L"ABHAOR",ACN) 


1 

228 


SEN0=1 


1 

229 


LASTBLK=1 


1 

230 


CALL OUTPT (SEND) 


1 

231 


CALL PROMPT(SEND) 


1 

232 


LASTBLK=0 


1 

233 


CALL OUTPT (SEND) 


1 

234 


INTRCHR=0 


1 

235 




1 

236 


RETURN 


1 

237 




1 

238 


END IF 



239 


RETURN 



240 





241 





242 

C 

PROCESS FC/INACT/R SUPERVISORY MESSAGE 



243 





244 

C 

UPDATE CONNECTION TABLE 



245 





246 


60 ACN=NFETCH(SMTA,L"FCACN") 



247 


NACN(ACN) = 0 



248 


HA=DSHDR 



249 


CALL NSTORE(HA,L"ABHADR",ACN) 



250 





251 





252 

C 

OUTPUT DISCONNECTION INDICATOR TO POSSIBLE OPERATOR 



253 





254 


TA(1)=" TIME OUT " 



255 


TA(2)=0 



256 





257 





258 

c 

NOTE THAT RMV2 DOES NOT WAIT FOR AN FC/ACK/R CORRESPONDING 

TO 


259 

c 

THIS OUTPUT MESSAGE. AN ERR/LGL/R MESSAGE WILL EVENTUALLY 



260 

c 

BE CAUSED BY THE CONNECTION TERMINATION PROCESSING CODE, 



261 

c 

CAUSING RMV2 TO NETOFF WITHOUT DEVICE OPERATOR 



262 

c 

OR HOST OPERATOR ACTION BEING REQUIRED. 



263 





264 


INSTAK(ACN)=OUTSTAK(ACN)=STAK(ACN)=0 



265 


SEND=1 



266 


LASTBLK=0 



267 


CALL OUTPT (SEND) 



268 





269 





270 

c 

PACK AND SEND CONNECTION-END REQUEST MESSAGE 



271 





272 


SMTA(1)=0 



273 


CALL NSTORE(SMTA,L"PFCSFC",CONEND) 



274 


C ALL NS TOR E(SHTA,L"CONA C N",ACN) 



275 


SMTA(2)=0 



276 


SMHA=SMHDR 



277 


CALL NETPUT (SMHA,SMTA) 



278 


RETURN 



279 





280 





281 

c 

PROCESS CON/CB/R SUPERVISORY MESSAGE 



282 





283 


70 ACN=NFETCH(SMTA,L"CONACN") 
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284 


PRINT 75,ACN 

285 


75 FORMATC CONNECTION BROKEN, ACN = ',13) 

286 



287 



288 

C 

FETCH ALL OUTSTANDING INPUT BLOCKS UNTIL A NULL 

289 

C 

BLOCK IS RECEIVED 

290 



291 


73 CALL NETGET(ACN,HA,TA,63) 

292 


IF (NFETCH(HA,L"ABHABT").EQ.O) GO TO 72 

293 



294 



295 

C 

DETERMINE WHETHER THIS IS A NORMAL SHUTD SEQUENCE FETCHED OUT OF 

296 

C 

SYNCHRONIZATION. IF SO, USE THE ERR/LGL/R LOGIC TO SHUT, DOWN. 

297 



298 


IF(TA(I).EQ.SHUTD) GO TO 76 

299 


GO TO 73 

300 



301 



302 

C 

CLEAN UP CONNECTION TABLE ENTRY AND AIP TABLES 

303 



304 


72 CALL NSTORE(SMTA,L"CONACN",ACN) 

305 


CALL NSTORE(SMTA,L"RC",0) 

306 


CALL NSTORE(SMTA,L"PFCSFC",CONENO) 

307 


SNHA=SNHDR 

308 


NACN(ACN)=0 

309 


CALL NETPUT(SMHA,SMTA) 

310 



311 


RETURN 

312 



313 



314 

C 

PROCESS FC/NAK/R SUPERVISORY MESSAGE 

315 



316 


80 ACN=NFETCH{SHTA,L"FCACN") 

317 


ABN(ACN)=NFETCH(SMTA,L"FCA8N"> 

318 


PRINT 1015,ACN,A8N(ACN) 

319 

1015 FORHATC ACN = ',I6-' ABN = ',110-' NOT DELIVERED') 

320 



321 


RETURN 

322 



323 



324 

C 

PROCESS CON/END/N SUPERVISORY MESSAGE 

325 

c 

PROCESSING TREATS THE MESSAGE AS ADVISORY IN ALL CASES. 

326 



327 


110 HSGLTH=410 

328 


NREWIND=0 

329 


IF((NSUP.AND.MC).GT.255) CALL NETREL(LFN,MSGLTH,NREWIND) 

330 



331 


RETURN 

332 



333 



334 

c 

PROCESS ERR/LGL/R SUPERVISORY MESSAGE, 

335 

c 

WRITE MESSAGE TO OUTPUT FILE FOR ANALYSIS, THEN SHUT 

336 

c 

DOWN OPERATIONS 

337 



338 


90 PRINT 1001,SHHA,SMTA 

339 

1001 FORMAT (IX,"HA = ",020,/1X,"TA = ",/1X,020,1X,020/,1X,020) 

340 
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341 

76 SMTA(1)=SHTA(2)=0 


342 

CALL NSTORE (SHTA,L"PFCSFC",CONEND) 


343 

CALL NSTORE(SHTA,L"RC",0) 


344 

SnHA=SHHDR 


345 

DO 333 11=1,20,1 


346 

IF CNACN(II).EQ.I) THEN 

1 

347 

CALL NSTORE (SHTA,L"CONACN",II) 

1 

348 

CALL NETPUT(SHHA,SMTA) 

1 

349 


1 

350 


1 

351 

C UPDATE CONNECTION TABLE 

1 

352 


1 

353 

NACN(II)=0 

1 

354 

END IF 

1 

355 



356 

333 CONTINUE 


357 



358 

CALL NETOFF 


359 

STOP 247 


360 



361 



362 

C PROCESS HOST OPERATOR TURN-DEBUGGING-ON COMMAND 


363 



364 

11 CONTINUE 


365 

RETURN 


366 



367 



368 

C PROCESS HOST OPERATOR TURN-DEBUGGING-OFF COMMAND 


369 



370 

21 CONTINUE 


371 

RETURN 


372 



373 



374 

C PROCESS HOST OPERATOR DUMP-FIELD-LENGTH COMMAND 


375 



376 

31 DUMPID=DUMPID + 1 


377 

ECS=1 


378 

CALL NETDMB (DUHPID,ECS) 


379 



380 

RETURN 


381 



382 



383 

C PROCESS HOST OPERATOR STOP-LOGGING COMMAND 


384 



385 

41 DBUGSUP=1 


386 

DUBDAT=1 


387 

CALL NETDBG {DBUGSUP,DBU6DAT,AVAIL) 


388 



389 

RETURN 


390 



391 



392 

C PROCESS HOST OPERATOR START-LOGGING COMMAND 


393 



394 

51 DBUGSUP=0 


395 

OBUGDAT=0 


396 

CALL NETDBG (DBUGSUP,DBUGDAT,AVAIL) 


397 
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398 

399 

400 

401 

402 

403 

404 

405 

406 

407 

408 

409 

410 

411 

412 

413 

414 

415 

416 

417 

418 

419 

420 

421 

422 

423 

424 

425 

426 

427 

428 

429 

430 

431 

432 

433 

434 

435 

436 

437 

438 

439 

440 

441 
1 442 

1 443 

1 444 

1 445 

1 446 

1 447 

1 448 

1 449 

1 450 

451 

452 


RETURN 


C PROCESS HOST OPERATOR RELEASE-LOG-FILE COMMAND 

61 MSGLTH=410 
NREUIND=0 

CALL NETREL (LFN,HSGLTH,NREgiND) 

RETURN 


C PROCESS HOST OPERATOR RESTART-STATISTICS COMMAND 
71 ONOFF=0 

CALL NETSTC CONOFF,AVAIL) 

RETURN 


C PROCESS THE BIMARK SYNCHRONOUS SUPERVISORY MESSAGE 


130 HA=SMHDR 
TA(1)=0 

CALL NSTORE (HA,L"ABHADR",ACN) 

CALL NSTORE (HA,L''ABHACT",2) 

CALL NST0RE<HA,L"ABHTLC",2) 

CALL NSTORECTA(1),L"PFCSFC",R0MARK) 
CALL NETPUT(HA,TA(1 )) 

CHANCLR=1 


RETURN 


C PROCESS SHUT/INSD/R SUPERVISORY MESSAGE, THEN 
C SHUTDOWN OPERATIONS 

C DETERMINE TYPE OF SHUTDOWN 

120 IBIT=NFETCH(SMTA,L"SHUTF") 


C IF THIS IS A FORCED SHUTDOWN, STOP NOW 
IF (IBIT.EQ.1) THEN 
CALL NETOFF 
STOP 313 

END IF 


C SHUTDOWN GRACEFULLY IF TIME PERMITS BY 
C DISCONNECTING ALL TERMINAL DEVICES 

CALL SHUTDN 
END 


Figure 7-2. Program Portion of RnV3 (Sheet 16 of 24) 


PAGE 8 


60499500 R 


7-17 




SUBROUTINE 

OUTPT 74/74 0PT=0,R0UND= A/ S/ M/-D,-0S FTN 5,1+599 83/08/05. 11.38.17 PAGE 1 



D0=-L0NG/ 

-0T,ARG=-C0MM0N/-FIXED-CS= USER/-FIXED-DB=-TB/-SB/-SL/ ER/-ID/-PMD/-ST,PL=5000 



FTN5,I=RMV, 

L=0UTPUT,L0=S/-A. 


1 

2 



SUBROUTINE OUTPT (SEND) 


3 

4 


C 

OUTPUT ONE DATA BLOCK 


6 



IMPLICIT INTEGER (A-Z) 


7 



COMMON /RMC0M/K(20),LASTBLK,I,S,NSUP,SMHDR,DSHDR,DSHDR1,NACN(20) 


8 



COMMON /RMCOM/CONEND,ROMARK,ACN,ABN(20),SM(20),ABL(20),ABHIBU,US 


9 



COMMON /RMCOM/NB (20),HA,INSTAK(20),0UTSTAK(20),ENDCN,SHUTD,INTRRSP 


10 



COMMON /RMCOH/INTRCHR,CHANRSt,CHANCLR 


11 



COMMON /RMCOH/TA(63),STAK(20),0VRFLHA(8,20),0VRFLTA(63,8,20),USI . 


12 



COMMON /RMC0M/IABN(20),SHHA,SMTA(63),SSM(8),MC,LFN,ABT,ACT,TLC 


13 





14 





15 


C 

IS There data In the main output buffer? 


16 





17 



IF (SEND.Ea.l) THEN 


18 





19 


C 

IF SO, IS THERE SOMETHING ELSE TO SEND FIRST? 


20 




1 

21 



IF (STAK(ACN) .EQ. 1) THEN 

1 

22 




1 

23 


C 

IF SO, ADD NEW OUTPUT TO STACK 

1 

24 




2 

25 



GO TO 1 

2 

26 



ELSE 

2 

27 




2 

28 


C 

IF not, test if new OUTPUT CAN BE SENT 

2 

29 




2 

30 



60 TO 9 

2 

31 



END IF 

1 

32 



ELSE 

1 

33 




1 

34 




1 

35 


C 

IF NOT, test if data NEEDS TO BE SENT FROM THE STACK 

1 

36 




1 

37 



60 To 8 

1 

38 



END IF 

1 

39 




1 

40 


C 

IS THERE DATA IN THE STACK? 

1 

41 





42 



8 IF (STAK(ACN) .EQ. 0) THEN 


43 





44 


C 

IF NOT, EXIT 


45 




1 

46 



RETURN 

1 

47 



ELSE 

1 

48 




1 

49 


C 

IF SO, Test if it can be sent 

1 

50 




1 

51 



GO TO 3 

1 

52 



END IF 

1 

53 




1 

54 




1 

55 


C 

CAN DATA BE SENT? 
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SUBROUTINE 

OUTPT 

74/74 0PT=0,R0UND= A/ S/ H/-D,-DS FTN 5.1+599 83/08/05. 11.38.17 PAGE 2 

1 

56 





57 


9 

IF (((NB(ACN).GE.ABL(ACN}>.AND.(CHANCLR.E9.0)).AND. 


58 



t (CHANRST.EQ.O)) THEN 


59 





60 

C 


IF NOT, STACK IT 


61 




1 

62 



STAK<ACN)=0UTSTAK(ACN)=INSTAK<ACN)=1 

1 

63 



0VRF LH A(INSTAK(ACN),AC N)=HA 

1 

64 



DO 888 JJ=1, 63, 1 

1 

65 


888 

OVRF LTA(J J,INSTAK(ACN),ACN)=TA <JJ) 

1 

66 



RETURN 

1 

67 




1 

68 

C 


IF SO, DO IT 

1 

69 




1 

70 



ELSE 

1 

71 




1 

72 

C 


UPDATE FLOW CONTROL ALGORITHM 

1 

73 




1 

74 



ABN(ACN)=ACN«64 + K(ACN) 

1 

75 



K(ACN)=K(ACN) + 1 

1 

76 



NB(ACN)=NB(ACN> + 1 

1 

77 



CALL NSTORE(HA,L"ABHABN",ABN(ACN)> 

1 

78 



CALL NETPUT(HA,TA) 

1 

79 



RETURN 

1 

80 



END IF 

1 

81 




1 

82 




1 

83 

C 

IS THERE ROOM FOR MORE DATA IN THE STACK? 

1 

84 




1 

85 

C 


IF NOT, THROW AWAY NEW OUTPUT 

1 

86 





87 


1 

IF (INSTAK(ACN).6T.0UTSTAK(ACN)) THEN 

1 

88 



IF ((INSTAK(ACN) - OUTSTAK(ACN)) .EQ. 7) THEN 

2 

89 



SEND=0 

2 

90 



RETURN 

2 

91 



END IF 

1 

92 



ELSE 

1 

93 



IF ((OUTSTAK(ACN) - INSTAK(ACN)) .EQ. 1) THEN 

2 

94 



SEND=0 

2 

95 



RETURN 

2 

96 



END IF 

1 

97 



END IF 

1 

98 

C 



1 

99 

C 


IF SO, SAVE THE NEW DATA 

1 

100 

c 




101 



INSTAK(ACN)=INSTAK(ACN) + 1 


102 



IF (INSTAK(ACN) .EQ. 9) INSTAK(ACN)=1 


103 



OVRFLHA(INSTAK(ACN),ACN)=HA 


104 



DO 999 11=1, 63, 1 


105 


999 

OVRFLTAd I, INSTAK (ACN) ,ACN)=TA(II) 


106 





107 





108 

c 

PROCESS DATA ALREADY IN STACK 


109 





110 

c 

CAN 

DATA BE SENT? 


111 





112 


3 

IF (NB(ACN) .GE. ABL(ACN)) THEN 
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SUBROUTINE 

OUTPT 

74/74 0PT=0,R0UND= A/ S/ M/-0,-DS FTN 5.1+599 83/08/05. 11.38.17 PAGE 3 


113 




114 

C 

IF NOT, EXIT 


115 



1 

116 


RETURN 

1 

117 



1 

118 

C 

IF SO, DO IT 

1 

119 



1 

120 


ELSE 

1 

121 



1 

122 

C 

UPDATE FLOW CONTROL ALGORITHM 

1 

123 



1 

124 


ABN(ACN>=ACN*64 + K(ACN) 

1 

125 


K(ACN)=K(ACN) + 1 

1 

126 


NB(ACN)=NB<ACN) + 1 

1 

127 


CALL NSTORE(OVRFLHA(OUTSTAK(ACN),ACN),L"ABHABN",ABN(ACN)) 

1 

128 


CALL NETPUT(OVRFLHA(OUTSTAK(ACN),ACN), 

1 

129 


+ OVRFLTA(1,OUTSTAK(ACN),ACN)) 

1 

130 



1 

131 

C 

TEST IF STACK HAS BEEN EMPTIED 

1 

132 



1 

133 


IF (OUTSTAK(ACN).EQ.INSTAK(ACN)) THEN 

2 

134 


STAK(ACN)=0 

2 

135 



2 

136 

C 

IF SO, REINITIALIZE POINTERS 

2 

137 



2 

138 


OUTSTAK(ACN)=INSTAK(ACN)=0 

2 

139 


ELSE 

2 

140 



2 

141 

C 

IF NOT, MOVE THE SEND BUFFER POINTER FOR NEXT PASS 

2 

142 



2 

143 


OUTSTAK(ACN)=OUTSTAK(ACN) + 1 

2 

144 


IF (OUTSTAK(ACN) .EQ. 9) OUTSTAK(ACN)=1 

2 

145 


RETURN 

2 

146 


END IF 

1 

147 


END IF 

1 

148 




149 


RETURN 


150 


END 
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SUBROUTINE PROMPT 74/74 0PT=0,R0UND= A/ S/ «/-D,-DS FTN 5.1+599 83/08/05. 11.38.17 

DO=-LONG/-OT,ARG=-COMMON/-FIXED,CS= USER/-FIXED,DB=-TB/-SB/-SL/ ER/-ID/-PMD/-ST,PL=5000 
FTN5,I=RHV,L=0UTPUT,L0=S/-A. 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 
17 


SUBROUTINE PROMPT (SEND) 

IMPLICIT INTEGER (A-Z) 

COMMON /RMCOM/K (20),LASTBLK,I,S,NSUP,SMHDR,DSHDR,DSHDR1,NACN(20) 
COMMON /RMC0M/C0NEND,R0MARK,ACN,ABN(20),SH(20),ABL(20),ABHI8U,US 
COMMON /RMC0M/NB(20),HA,INSTAK(20),0UTSTAK(20),ENDCN,SHUT0,INTRRSP 
COMMON /RMCOM/INTRCHR,CHANRST,CHANCLR 

COMMON /RMC0M/TA(63),STAK(20),0VRFLHA(8,20),0VRFLTA(63,8,20),US1 
COMMON /RMC0M/IABN(20),SMHA,SMTA(63),SSM(8),MC,LFN,ABT,ACT,TLC 

HA=DSHOR 

CALL NSTORE(HA,L"ABHADR",ACN) 

TA(1)=" INPUT PLS" 

TA(2)=0 

SEND=1 

RETURN 

END 
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SUBROUTINE SETUP 74/74- 0PT=0,R0UND= A/ S/ H/-D,-DS FTN 5.1+599 83/08/05.11.38.17 

DO=-LONG/-OT,ARG=-COHnON/-fIXED,CS= USER/-F1XED,DB=-TB/-SB/-SL/ ER/-ID/-PMD/-ST,PL=5000 
FTN5,I=RHV,L=0UTPUT,L0=S/-A. 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 


SUBROUTINE SETUP 
IMPLICIT INTEGER(A-Z) 

COMMON /RMCOM/K(20),LASTBLK,I,S,NSUP,SMHDR,DSHDR,0SHDR1,NACN(20) 
COMMON /RMCOM/CONEND,ROMARK,ACN,ABN(20),SMC20),ABL(20),ABHIBU,US 
COMMON /RMC0M/NB(20),HA,INSTAK(20),0UTSTAK{20),ENDCN,SHUT0,INTRRSP 
COMMON /RMCOM/INTRCHR,CHANRST>CHANCLR 

COMMON /RMCOM/TA(63),STAK(20),OVRFLHA<8,20),OVRFLTA(63,8,20),US1 
COMMON /RHC0M/IABN(20),SMHA,SMTA<63),SSH(8),MC,LFN,ABT,ACT,TLC 


C SET OUTGOING SUPERVISORY MESSAGE CONSTANTS 

C0NEND=NFETCH(0,L"CONEND") 
ROMARK=NFETCH(0,L"R0MARK") 
INTRRSP=NFETCH(0,L"INTRRSP") 


C BUILD A BRANCHING TABLE FOR INCOMING SUPERVISORY 
C MESSAGES (NOTE THAT THIS TABLE IS USED IN A MANNER 
C THAT PERMITS EXPANSION) 

SM(1 )=NFETCH(0,L"FCACK") 

SM(2)=NFETCH(0,L"C0NRE«") 

SM(3)=NFETCH(0,L"FCINIT") 

SM(4)=NFETCH(0,L"INTRUSR") 

SM(5)=NFETCH(0,L"FCINA") 

SM(6)=NFETCH(0,L"C0NCB") 

SM (7 ) =N F ETC H (0 , L" F CNAK ") 
SM(8)=NFETCH(0,L"ERRLGL") 
SM(9)=NFETCH(0,L"H0P") 
SM(10)=NFETCH(0,L"CONENO") 


C SET RESPONSE BIT FOR THE CON/END/N MESSAGE 

SM(10)=SM(10) .OR.O"100" 

SM(11)=NFETCH{0,L"SHUINS") 

SH(12)=NFETCH (0,L"BIHARK") 

SM(13)=999 


C BUILD A BRANCHING TABLE FOR HOST OPERATOR COMMANDS 

SSMd )=NFETCH (0,L"H0PDB") 

SSM(2)=NFETCH (0,L"H0PDE") 

SSM(3)=NFETCH(0,L"HOPDU") 

SSM(4)=NFETCH(0,L"HOPN0TR") 

SSM(5)=NFETCH(0,L"H0PTRCE") 

SSM(6)=NFETCH(0,L"HOPREL") 

SSM(7)=NFETCH(0,L"H0PRS") 

RETURN 

END 
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SUBROUTINE PACK 74/74 0PT=0,R0UND= A/ S/ M/-D,-DS FTN 5.1+599 83/08/05. 11.38.17 

PAGE 1 


D0=-L0NG/-0T, 

,ARG=-COMMON/-FIXED,CS= USER/-F1XED,0B=-TB/-SB/-SL/ ER/-ID/-PHD/-ST,PL=5000 



FTN5,I=RHV,L=0UTPUT,L0=S/-A. 



1 

SUBROUTINE PACK (SEND) 



3 

IMPLICIT INTEGER(A-Z) 



4 

COMMON /RMCOM/K(20),LASTBLK,I,S,NSUP,SHHDR,0SHDR,DSHDR1,NACN(20) 



5 

COMMON /RMCOM/CONEND,ROMARK,ACN,ABN(20),SM(20),ABL(20),ABHIBU,US 



6 

COMMON /RMCOH/NB(20),HA,INSTAK(20),OUTSTAK(20),ENDCN,SHUTD,INTRRSP 



7 

COMMON /RMCOM/INTRCHR,CHANRST,CHANCLR 



8 

COMMON /RMCOM/TA(63),STAK(20),OVRFLHA(8,20),OVRFLTA(63,8,20),US1 



9 

COMMON /RMC0H/IABN(20),SMHA,SMTA(63),SSM(8),MC,LFN,ABT,ACT,TLC 



10 

11 

12 C 

13 

CREATE HEADER WORD TO ECHO INPUT AS OUTPUT 



14 

HA =(HA .AND. O"77777777777774007777") + 0"1" 



15 

16 

17 C 

CHANGE APPLICATION BLOCK TYPE TO 1 



18 

IF (ABT.E().2> CALL NSTORE (HA,L"ABHABT",1) 



19 

IF (ABT.EQ.2) THEN 


1 

20 

LASTBLK=1 


1 

21 

ELSE 


1 

22 

LAST8LK=0 


1 

23 

END IF 


1 

24 



1 

25 



1 

26 C 

INHIBIT FIRST CHARACTER AS A FORMAT EFFECTOR 


1 

27 




28 

CALL NSTORE(HA,L"ABHNFE",1) 



29 

30 

31 C 

32 

ECHO INPUT AS OUTPUT, AFTER ADDING A US TERMINATOR 



33 

FULH0=TLC/5 



34 

FMP1=FULHD+1 



35 

XTRA=12*(TLC - 5*FULHD) 



36 

TLC=TLC + 1 



37 

CALL NSTORE(HA,L"ABHTLC",TLC> 



38 

IF (XTRA.EQ.O) THEN 


1 

39 

TA{FHP1)=US 


1 

40 

ELSE 


1 

41 

XXX=SHIFT(US1,-XTRA) 


1 

42 

YYY=SHIFT(US,-XTRA) 


1 

43 



1 

44 



1 

45 C 

ZERO OUT REMAINDER OF WORD AND ADD UNIT SEPARATOR CHARACTER TO END OF BLOCK 


1 

46 



1 

47 

TA(FWP1)=TA(FWP1) .AND. XXX .OR. YYY 


1 

48 

END IF 


1 

49 




50 

SEND=1 



51 

RETURN 



52 

END 
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SUBROUTINE SHUTDN 74/74 0PT=0,R0UND= A/ S/ «/-D,-DS FTN 5.1+599 83/08/05. 11.38.17 PAGE 1 

00=-L0NG/-0T,ARG=-C0WM0N/-FIXED,CS= USER/-FIXED,DB=-TB/-SB/-SL/ ER/-ID/-PI»ID/-ST,PL=5000 
FTN5,I=RMV,L=0UTPUT,L0=S/-A. 


1 SUBROUTINE SHUTDN 

2 

3 IMPLICIT INTEGER(A-Z) 

COMMON /RHCOM/K(20),LASTBLK,I,S,NSUP,SMHDR,DSHDR,DSHDR1,NACN(20) 
COMMON /RMCOM/CONEND,ROHARK,ACN,ABN(20),SM(20),ABL(20),ABHIBU,US 
COMMON /RMCOM/NB (20) ,HA,INSTAK (20) ,OUTSTAK (20) ,ENOCN,SHUT.O,INTRRSP 
COMMON /RMCOH/INTRCHR,CHANRST,CHANCLR 

COMMON /RMC0H/TA(63),STAK(20),OVRFLHA(8,20),OVRFLTA(63,8,20),US1 
COMMON /RMCOH/IABN(20),SHHA,SHTA(63),SSM(8),HC,LFN,ABT,ACT,TLC 


C CLEANUP ALL CONNECTIONS BEFORE ENDING NETWORK ACCESS 

666 SMTA(1)=SMTA(2)=0 

CALL NSTORE(SHTA,L"PFCSFC",CONEND) 

CALL NSTORE(SMTA,L"RC",0) 


C PASS CONNECTION DIRECTLY TO lAF WITHOUT DIALOG 

CALL NST0RE(SMTA,L"C0NANM",R"1AF ") 
SMHA=SHH0R + 0"1" 

DO 555 J=1,20 
IF (NACN(J).EQ.I) THEN 
CALL NSTORE (SMTA,L"CONACN",J) 

NACN(J)=0 

CALL NETPUT (SMHA,SMTA) 

END IF 

555 CONTINUE 


C FETCH ALL QUEUED SUPERVISORY MESSAGES TO AVOID AN APPLICATION 
C FAILED MESSAGE TO THE DEVICE OPERATOR AFTER DISCONNECTION 

97 CALL NETWAIT(5,0) 

SHUTDWN=1 

SYNC=0 

CALL LOOKSM (SHUTDWN,L,SYNC) 

IF (L.EQ.3) GO TO 666 
IF (L.LE.12) GO TO 97 


C FINISH WRITING DEBUG LOG AND STATISTICAL FILES 
CALL NETOFF 
STOP 333 
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SUBROUTINE REPREV 74/74 0PT=0,R0UND= A/ S/ M/-D,-DS FTN 5.1+599 83/08/05. 11.38.17 PAGE 1 

DO=-LONG/-OT,ARG=-COMHON/-FIXED,CS= USER/-FIXED,DB=-TB/-SB/-SL/ ER/-ID/-PWD/-ST,PL=5000 
FTN5,I=RHV,L=OUTPUT,LO=S/-A. 

1 SUBROUTINE REPREV CIXCHNG,IFLAG,IFLDLN) 

2 

3 

4 C THIS SUBROUTINE SALVAGES THE DEBUG AND STATISTICAL FILE ENTRIES BY 

5 C CALLING THE AIP ROUTINE NETOFF TO FLUSH BUFFERS IN CASE THE 

6 C APPLICATION PROGRAM IS ABORTED DURING EXECUTION 

7 

8 

9 DIMENSION IXCHMG(26),IFLOLNCO"50000") 

10 IFLAG=1 

11 

12 CALL NETOFF 

13 STOP 10 

14 

15 ENTRY CHKSUM 

16 END 


Figure 7-2. Program Portion of RHV3 (Sheet 24 of 24) 


RMV2 VER3 


INPUT PLS Prompt to operator from RMV2 for first input. 


User-break-1 or 
user-break-2 

BREAK n 

INPUT PLS 

Entered by terminal operator. 

RMV2 response to break entries. 

Prompt for next input. 

BYPASSED 

RHV2 response to INTR/USR/R supervisory message. 

TIME OUT 

RMV2 output documenting an inactive connection; this is.followed by disconnection 
from RMV2 for subsequent terminal operator dialog with NVF or disconnection from 
the host. 

INPUT PLS 

RHV2 prompt for next input. 

SHUTD 

Terminal operator entry, causes normal connection termination for this terminal 
and for all other connected terminals. Next terminal operator dialog is with lAF, 
if that program is available. 

INPUT PLS 

RHV2 prompt for next input. 

ENDCN 

Terminal operator entry, causes normal connection termination for this terminal. 
Next terminal operator dialog is with lAF, if that program is available. 

INPUT PLS 

RMV2 prompt for input. 

Any characters 
other than SHUTD or 
ENDCN, up to 314 

Terminal operator entry. 

Any characters 
other than SHUTD or 
ENDCN, up to 314 

RHV2 echoed output, single-spaced. 

INPUT PLS 

RMV2 prompt for next entry. 


Figure 7-3. Possible Dialogs Supported by Sample FORTRAN Program 
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RHV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00001 


11.38.26.000 NETON (024677) ANAME = RHV2 DATE = 83/08/05 MSG NO. 000001 

NSUP ADOR = 000140 MINACN =00001 MAXACN =00020 


11.38.53.498 NETGETL (031354) ALN. ^^0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000002 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0010 


001 630000001600200 30600000000130001000 .CONREQ C 
002 51C75F0ADB45018 24343537025555050030 T124B E X UP-4P 

003 0000000000006EA 00000000000000003352 0) N 

004 0000000002DD40B 00000000000013352013 K2PK -T 

005 XXXXXXX6DB40011 xxxxxxxxxxx555000021 xxxxx Q H B Ca 

006 xxxxxxxEI880037 xxxxxxxxxxxxxx000067 xxxxxxx S 16A 7 

007 000FF8FFFFFFFFF 00007770777777777777 i'iiiiii X 

008 FFF3400001FFFFF 77771500000007777777 ;;M G;;; _4-32. 

009 000000000000F6F 00000000000000007557 . V 

010 7C014034460D1C1 37000500150430150701 4 E MDXHGA wa oaaA 


11.38.53.508 NETPUT (031655) HA =024544 TA =024545 MSG NO. 000003 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 6340000010000Cl 30640000000100000301 CONREQN Ca 


11.38.54.007 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000004 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830700001000000 40603400000100000000 FCINIT 


11.38.54.010 NETPUT (031655) HA =024544 TA =024545 MSG NO. 000005 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


001 834700001000000 40643400000100000000 FCINITN G 


11.38.54.011 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000006 

ABT =01 ADR =0001 ABN =000065 ACT =04 STATUS = 00000000 TLC = 0020 

001 71235676D58549E 34221526355526052236 1RHV2 VER3 a#VVU I 

002 000000000000000 00000000000000000000 a 


11.38.54.011 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000007 

ABT =02 ADR =0001 ABN =000066 ACT =04 STATUS = 00000000 TLC = 0020 

001 B49390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.38.54.505 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000008 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 1 of 13) 
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RMV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00002 


001 830200001001040 40601000000100010100 FCACK 


11.38.54.509 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000009 

A0T =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001080 40601000000100010200 FCACK 


11.39.10.797 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 000010 

ABT =02 ADR =0001 ABN =000000 ACT =03 STATUS = 00000000 TLC = 0047 

001 05406806502006E 01240150014500400156 ATA/A+ 5A, THE N 
002 065078074020063 01450170016400400143 A+A'A" 5A8 EXT C 
003 068061072061063 01500141016201410143 A/A6A3A6A8 HARAC 
004 074065072020069 01640145016200400151 A"A+A] 5A( TER 1 
005 073020061020075 01630040014100400165 A% 5A6 5A S A U 
006 07306507202D062 01630145016200550142 A%A+AD A7 SER-B 
007 07206506106B02D 01620145014101530055 ADA+A6A$ REAK- 
008 031020063068061 00610040014301500141 C 5A8A/A6 1 CHA 

009 072061063074065 01620141014301640145 A]A6A8A"A+ RACTE 
010 07202E000000000 01620056000000000000 A] , R. 


11.39.10.804 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000011 

ABT =01 ADR =0001 ABN =000067 ACT =03 STATUS = 00001000 TLC =0048 

001 05406806502006E 01240150014500400156 ATA/A+ 5A, THE N 
002 065078074020063 01450170016400400143 A+A'A" 5A8 EXT C 
003 068061072061063 01500141016201410143 A/A6A3A6A8 HARAC 
004 074065072020069 01640145016200400151 A"A+A3 5A( TER I 
005 073020061020075 01630040014100400165 AX 5A6 5A S A U 
006 07306507202D062 01630145016200550142 AXA+AD A7 SER-B 
007 07206506106B02D 01620145014101530055 A]A+A6A$ REAK- 
008 031020063068061 00610040014301500141 C 5A8A/A6 1 CHA 

009 072061063074065 01620141014301640145 A3A6A8A"A+ RACTE 
010 07202E01F000000 01620056003700000000 A3 , 4 R. 


11.39.10.805 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000012 

ABT =02 ADR =0001 ABN =000068 ACT =04 STATUS = 00000000 TLC = 0020 

001 B49390554B50313 55111620252455201423 INPUT PLS 4 UKP1 
002 000000000000000 00000000000000000000 0 


11.39.11.844 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000013 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001OCO 40601000000100010300 FCACK 


11.39.11.850 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000014 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 2 of 13) 
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7-27- 




RMV2 LOG FILE OUTPUT 83/08/05 

DATE RECORDED - 83/08/05 PAGE 00003 


ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


001 830200001001100 40601000000100010400 FCACK 


,11.39.15.953 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000015 

; ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 800003001000000 40000003000100000000 INTRUSR 


11.39.15.957 NETPUT (031655) HA =024544 TA =024545 MSG NO. 000016 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


001 800100001000000 40000400000100000000 INTRRSP 


11.39.16.011 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 000017 

ABT =03 ADR =0001 ABN =000000 ACT =02 STATUS = 00000000 TLC = 0002 

001 CAOOOOOOOOOOOOO 62400000000000000000 BIMARK J 


11.39.16.043 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000018 

ABT =03 ADR =0001 ABN =000000 ACT =02 STATUS = 00000000 TLC = 0002 


001 CBOOOOOOOOOOOOO 62600000000000000000 ROMARK K 


11.39.16.043 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000019 

ABT =01 ADR =0001 ABN =000069 ACT =04 STATUS = 00000000 TLC = 0020 


001 B4248504BB5CB6D 55022205011355345555 BREAK 1 4$ ; 6 

002 000000000000000 00000000000000000000 P 


11.39.16.043 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000020 

ABT =02 ADR =0001 ABN =000070 ACT =04 STATUS = 00000000 TLC = 0020 

001 B49390554850313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.39.17.006 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000021 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000000 40601000000100000000 FCACK 


11.39.17.010 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000022 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001140 40601000000100010500 FCACK 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 3 of 13) 
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RHV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00004 


11.39.17.014 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001180 40601000000100010600 FCACK 


11.39.32.490 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 

ABT =02 ADR =0001 ABN =000000 ACT =03 STATUS = 00000000 TLC = 0047 


001 05406806502006E 
002 065078074020063 
003 068061072061063 
004 074065072020069 
005 073020061020075 
006 07306507202D062 
007 07206506106B02D 
008 032020063068061 
009 072061063074065 
010 07202EOOOOOOOOO 


012401500145004001 56 
01450170016400400143 
01500141016201410143 
01640145016200400151 
01630040014100400165 
01630145016200550142 
01620145014101530055 
00620040014301500141 
01620141014301640145 
01620056000000000000 


ATA/A+ 5A, 

THE N 

A+A'A" 5A8 

EXT C 

A/A6A3A6A8 

HARAC 

A"A+A] 5A( 

TER I 

A% 5A6 5A 

S A U 

A%A+AD PiT 

SER-B 

A3A+A6AS 

REAK- 

3 5A8A/A6 

2 CHA 

A3A6A8A"A+ 

RACTE 

n 

< 

R. 


11.39.32.502 NETPUT (031655) HA =000315 TA =000374 MSG NO. 

ABT =01 ADR =0001 ABN =000071 ACT =03 STATUS = 00001000 TLC = 0048 


001 05406806502006E 
002 065078074020063 
003 068061072061063 
004 074065072020069 
005 073020061020075 
006 07306507202D062 
007 07206506106B02D 
008 032020063068061 
009 072061063074065 
010 07202E01F000000 


01240150014500400156 
01450170016400400143 
01500141016201410143 
01640145016200400151 
01630040014100400165 
01630145016200550142 
01620145014101530055 
00620040014301500141 
01620141014301640145 
01620056003700000000 


ATA/A+ 5A, 

THE N 

A+A'A" 5A8 

EXT C 

A/A6A3A6A8 

HARAC 

A"A+A3 5A( 

TER I 

A% 5A6 5A 

S A U 

A%A+A3 AT 

SER-B 

A3A+A6A$ 

REAK- 

3 5A8A/A6 

2 CHA 

A3A6A8A"A+ 

RACTE 

A3 , 4 

R. 


11.39.32.502 NETPUT (031655) HA =000315 TA =000374 MSG NO. 

ABT =02 ADR =0001 ABN =000072 ACT =04 STATUS = 00000000 TLC = 0020 

001 B49390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.39.34.047 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


001 830200001001 ICO 40601000000100010700 FCACK 


11.39.34.067 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001200 40601000000100011000 FCACK 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 4 of 13) 
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000024 
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000026 


000027 


000028 
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RHV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00005 


11.39.36.687 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000029 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 800004001000000 40000004000100000000 INTRUSR 


11.39.36.740 NETPUT (031655) HA =024544 TA =024545 MSG NO. 000030 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 800100001000000 40000400000100000000 INTRRSP 


11.39.36.811 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 000031 

ABT =03 ADR =0001 ABN =000000 ACT =02 STATUS = 00000000 TLC = 0002 

001 CA00000901DE000 62400000022007360000 BIHARK J 


11.39.36.822 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000032 

ABT =03 ADR =0001 ABN =000000 ACT =02 STATUS = 00000000 TLC = 0002 

001 CBOOOOOOOOOOOOO 62600000000000000000 ROMARK K 


11.39.36.822 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000033 

ABT =01 ADR =0001 ABN =000073 ACT =04 STATUS = 00000000 TLC = 0020 

001 B4248504B85DB6D 55022205011355355555 BREAK 2 4$ ;:6 

002 000000000000000 oooooooooooooboooooo P 


11.39.36.823 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000034 

ABT =02 ADR =0001 ABN =000074 ACT =04 STATUS = 00000000 TLC = 0020 

001 B49390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.39.37.707 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000035 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000000 40601000000100000000 FCACK 


11.39,37.711 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000036 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001240 40601000000100011100 FCACK $ 


11,39.37.715 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000037 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 5 of 13) 
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RHV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00006 


001 830200001001280 40601000000100011200 FCACK ( 


11.39.51.219 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 000038 

ABT =02 ADR =0001 ABN =000000 ACT =03 STATUS = 00000000 TLC = 0036 

001 05406806502006E 01240150014500400156 ATA/A+ 5A, THE N 
002 065078074020065 01450170016400400145 A+A'A" 5A+ EXT E 
003 06E074072079020 01560164016201710040 A,A"A3A? 5 NTRY 
004 069073020061020 01510163004001410040 A(A% 5A6 5 IS A 
005 062072065061060 01420162014501410153 A7ADA+A6A$ BREAK 
006 02006306F06E064 00400143015701560144 5A8A.A,A9 COND 

007 06907406906F06E 01510164015101570156 A(A"ACA.A, ITION 
008 02EOOOOOOOOOOOO 00560000000000000000 , 


11.39.51 .225 NETPUT (031655) HA =000315 TA =000374 HSG NO. 000039 

ABT =01 ADR =0001 ABN =000075 ACT =03 STATUS = 00001000 TLC = 0037 

001 05406806502006E 01240150014500400156 ATA/A+ 5A, THE N 
002 065078074020065 01450170016400400145 A+A’A" 5A+ EXT E 
003 06E074072079020 01560164016201710040 A,A"A3A? 5 NTRY 
004 069073020061020 01510163004001410040 A(A% 5A6 5 IS A 
005 062072065061066 01420162014501410153 A7A3A+A6A$ BREAK 
006 02006306F06E064 00400143015701560144 5A8A.A,A9 COND 

007 06907406906F06E 01510164015101570156 A(A"A(A.A, ITION 
008 02E01F000000000 00560037000000000000 , 4 


11.39.51.225 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000040 

ABT =02 ADR =0001 ABN =000076 ACT =04 STATUS = 00000000 TLC = 0020 

001 B49390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.39.51.747 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000041 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 8302000010012C0 40601000000100011300 FCACK 


11.39.51.751 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000042 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001300 40601000000100011400 FCACK 0 


11.39.56.410 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000043 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 800003001000000 40000003000100000000 INTRUSR 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 6 of 13) 
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RMV2 LOG FILE OUTPUT 83/08/05 

DATE RECORDED - 83/08/05 PAGE 00007 


11.39.56.414 NETPUT (031655) HA =024544 TA =024545 MSG NO. 000044 ■ 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 800100001000000 40000400000100000000 INTRRSP 


11.39.56.464 - NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. ,000045 

ABT =03 ADR =0001 ABN =000000 ACT =02 STATUS = 00000000 TLC = 0002 

001 CAOOOOOOOOOOOOO 62400000000000000000 BINARK J 


11.39.56.478 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000046 

ABT =03 ADR =0001 ABN =000000 ACT =02 STATUS = 00000000 TLC = 0002 

001 CBOOOOOOOOOOOOO 62600000000000000000 ROMARK K 


11.39.56.478 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000047 

ABT =01 ADR =0001 ABN =000077 ACT =04 STATUS = 00000000 TLC = 0020 

001 B4248504BB5CB6D 55022205011355345555 BREAK 1 4$ ; 6 

002 000000000000000 00000000000000000000 P 


11.39.56.478 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000048 

ABT =02 ADR =0001 ABN =000078 ACT =04 STATUS = 00000000 TLC = 0020 


001 B49390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.39.56.960 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000049 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000000 40601000000100000000 FCACK 


11.39.56.964 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000050 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001340 40601000000100011500 FCACK 4 


11.39.56.992 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000051 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001380 40601000000100011600 FCACK 8 


11.39.57.021 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 000052 

ABT =02 ADR =0001 ABM =000000 ACT =03 STATUS = 00000000 TLC = 0000 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 7 of 13) 
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RHV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00008 


11.39.57.027 NETPUT C031655) HA =000315 TA =000374 

ABT =01 ADR =0001 ABN =000079 ACT =03 STATUS = 00001000 TLC = 0001 

001 01F000000000000 00370000000000000000 4 

11.39.57.028 NETPUT (031655) HA =000315 TA =000374 

ABT =02 ADR =0001 ABN =000080 ACT =04 STATUS = 00000000 TLC = 0020 

001 849390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 

11.39.57.501 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 8302000010013C0 40601000000100011700 FCACK < 

11.39.57.505 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLHAX =0063 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001400 40601000000100012000 FCACK a 

11.40.12.998 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 

ABT =02 ADR =0001 ABN =000000 ACT =03 STATUS = 00000000 TLC = 0005 

001 04504E04404304E 01050116010401030116 AEANADACAN ENDCN 

11.40.13.005 NETPUT (031655) HA =024544 TA =024545 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0002 

001 630600001000000 30603000000100000000 CONENO C 

002 2411ADB6DB40000 11010655555555000000 lAF A D«14 

11.40.13.064 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 634600001000000 30643000000100000000 CONENDN CF 


MSG NO. 000053 


MSG NO. 000054 


MSG NO. 000055 


MSG NO. 000056 


MSG NO. 000057 


MSG NO. 000058 


MSG NO. 000059 


11.40.29.864 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLHAX =0063 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0010 


MSG NO. 000060 


003 0000000000006EA 00000000000000003352 
004 0000000002DD40B 00000000000013352013 


CONREQ 

C 


T124B E X 


UP-4P 

0) 


N 

K2PK 


-T 

xxxxx Q 

M 

B ca 

xxxxxxx & 


16A ■ 
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RMV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00009 


007 000FF8FFFFFFFFF 00007770777777777777 X_ 

008 FFF3400001FFFFF 77771500000007777777 ;;H G;;; _4 

009 000000000000F6F 00000000000000007557 . V 


010 7C014034460D1C1 37000500150430150701 4 E MDXMGA WS) DSIQA 


11.40.29.870 NETPUT (031655) . . HA =024544 ,TA =024545 MSG NO. 000061 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 634000001OOOOC1 30640000000100000301 CONREQN Ca 


11.40.30.922 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLHAX =0063 MSG NO. 000062 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830700001000000 40603400000100000000 FCINIT 


11.40.30.925 NETPUT (031655) HA =024544 TA =024545 MSG NO. 000063 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 834700001000000 40643400000100000000 FCINITN G 


11.40.30.925 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000064 

ABT =01 ADR =0001 ABN =000081 ACT =04 STATUS = 00000000 TLC = 0020 

001 71235676D58549E 34221526355526052236 1RMV2 VER3 Q#VVU I 

002 000000000000000 00000000000000000000 a 


11.40.30.925 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000065 

ABT =02 ADR =0001 ABN =000082 ACT =04 STATUS = 00000000 TLC = 0020 

001 849390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.40.31.468 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000066 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001440 40601000000100012100 FCACK 0 


11.40.31.473 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000067 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001480 40601000000100012200 FCACK H 


11.41.39.064 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLHAX =0010 MSG NO. 000068 

ABT =00 ADR =0001 ABN =000000 ACT =02 STATUS = 10000000 TLC = 0100 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 9 of 13) 
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RMV2 

LOG FILE OUTPUT 



83/08/05 



DATE RECORDED - 83/08/05 



PAGE 00010 

11.41.39 

.077 NETGET (031340) ACN =0001 HA =000315 TA =000374 TLHAX 

=0063 

MSG 

NO. 000069 

ABT =01 

ADR =0001 ABN 

=000000 ACT =03 STATUS = 00000000 TLC = 0100 




001 

054068069073020 

01240150015101630040 

ATA/A(A% 5 

THIS 




002 

069073020061020 

01510163004001410040 

A(A% 5A6 5 

IS A 




003 

074065073074020 

0164014501 6301640040 

A"A+A%A" 5 

TEST 




004 

06F066020074068 

01570146004001640150 

A.A- 5A"A/ 

OF TH 




005 

065020071075065 

01450040016101650145 

A+ 5ACA A+ 

E QUE 




006 

07506906E067020 

01650151015601470040 

A A(A,A* 5 

UING 




007 

06306F064065020 

01430157014401450040 

A'SA.A9A+ 5 

CODE 




008 

06606F07202006D 

01460157016200400155 

A-A.A] 5A 

FOR H 




009 

065073 073061067 

01450163016301410147 

A+A%A%A6A* 

ESSAG 




010 

06507302006F066 

01450163004001570146 

A+A% 5A.A- 

ES OF 




Oil 

02006D06F072065 

00400155015701620145 

5A a.a:a+ 

MORE 




012 

02007406806106E 

00400164015001410156 

5A"A/A6A, 

THAN 




013 

02006F06E065020 

00400157015601450040 

5A.A,A+ 5 

ONE 




014 

06E06507407706F 

01560145016401670157 

A,A+A"A&A. 

NETWO 




015 

072068020064061 

016201 53004001440141 

A3A$ 5A9A6 

RK DA 




016 

07406102006206C 

01640141004001420154 

A"A6 5A7A= 

TA BL 




017 

06F06306B03B020 

01570143015300730040 

A.A8A$ > 5 

OCK; 




018 

074068069073020 

01640150015101630040 

A"A/A(A5! 5 

THIS 




019 

06906E070075074 

01510156016001650164 

A(A,A#A A" 

INPUT 




020 

02007306806F075 

00400163015001570165 

5A%A/A.A 

SHOU 




11.41.39 

083 NETPUT (031655) HA =000315 TA =000374 


MSG 

NO. 000070 

ABT =01 

ADR =0001 ABN 

=000083 ACT =03 STATUS = 00001000 TLC = 0101 




001 

054068069073020 

01240150015101630040 

ATA/A(A% 5 

THIS 




002 

069073020061020 

01510163004001410040 

A(A5i 5A6 5 

IS A 




003 

074065073074020 

01640145016301640040 

A"A+A%A" 5 

TEST 




004 

06F066020074068 

01570146004001640150 

A.A- 5A"A/ 

OF TH 




005 

065020071075065 

01450040016101650145 

A+ 5ACA A+ 

E DUE 




006 

07506906E067020 

01650151015601470040 

A A(A,A* 5 

UING 




007 

06306F064065020 

014301 57014401450040 

A8A.A9A+ 5 

CODE 




008 

06606F07202006D 

01460157016200400155 

A-A.A] 5A 

FOR M 




009 

065073073061067 

01450163016301410147 

A+A%A%A6A* 

ESSAG 




010 

06507302006F066 

01450163004001570146 

A+A% 5A.A- 

ES OF 




Oil 

02006D06F072065 

00400155015701620145 

5A A.ADA+ 

MORE 




012 

02007406806106E 

00400164015001410156 

5A"A/A6A, 

THAN 




013 

02006F06E065020 

00400157015601450040 

5A.A,A+ 5 

ONE 




014 

06E06507407706F 

01560145016401670157 

A,A+A"ASA. 

NETWO 




015 

07206B020064061 

016201 53004001440141 

A3A$ 5A9A6 

RK DA 




016 

07406102006206C 

01640141004001420154 

A"A6 5A7A= 

TA BL 




017 

06F06306B03B020 

01570143015300730040 

A.A8A$ > 5 

OCK; 




018 

074068069073020 

01640150015101630040 

A"A/A(A% 5 

THIS 




019 

06906E070075074 

0151015601 6001650164 

A(A,A#A A" 

INPUT 




020 

02007306806F075 

00400163015001570165 

5A%A/A.A 

SHOU 




021 

01 F 000000000000 

00370000000000000000 

4 ~ 





11.41.42. 

759 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX 

=0063 

MSG 

NO. 000071 

ABT =03 

ADR =0000 ABN 

=000000 ACT =01 STATUS = 00000000 TLC = 0001 





Figure 7-4. Debug Log FiLe Listing for Sample FORTRAN Program (Sheet 10 of 13) 
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RHV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00011 


001 830200001OOUCO 40601000000100012300 FCACK L 


11.41.42.791 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 000072 

ABT =00 ADR =0001 ABN =000000 ACT =02 STATUS = 10010000 TLC = 0070 


11.41.42.823 NETGET (031340) ACN =0001 HA =000315 TA =000374 TLMAX =0063 MSG NO. 000073 

ABT =02 ADR =0001 ABN =000000 ACT =03 STATUS = 00010000 TLC = 0070 

001 06C064020067065 01540144004001470145 A=A9 5A*A+ LD GE 
002 06E065072061074 01560145016201410164 A,A+A]A6A" NERAT 
003 065020073065076 01450040016301450166 A+ 5A%A+A! E SEV 
004 06507206106C020 01450162014101540040 A+A3A6A= 5 ERAL 
005 06206C06F06306B 01420154015701430153 A7A=A.A8A$ BLOCK 
006 07302006F066020 01630040015701460040 A% 5A.A- 5 S OF 
007 06906E070075074 01510156016001650164 A(A,A#A A" INPUT 
008 02006106E064020 00400141015601440040 5A6A,A9 5 AND 

009 06F075074070075 01570165016401600165 A.A_A"A#A_ OUTPU 
010 07402006106E064 01640040014101560144 A" 5A6A,A9 T AND 
011 020062065020070 00400142014500400160 5A7A+ 5A# BE P 

012 07206F070065072 01620157016001450162 ATA.A#A+a: ROPER 
013 06C079020065063 01540171004001450143 A=A? 5A+A8 LY EC 
014 06806F06506402E 01500157014501440056 A/A.A+A9 , HOED. 


11.41.42.843 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000074 

ABT =01 ADR =0001 ABN =000084 ACT =03 STATUS = 00001000 TLC = 0071 

001 06C064020067065 01540144004001470145 A=A9 5A*A+ LD GE 
002 06E065072061074 01560145016201410164 A,A+ADA6A" NERAT 
003 065020073065076 01450040016301450166 A+ 5A%A+A! E SEV 
004 06507206106C020 01450162014101540040 A+A3A6A= 5 ERAL 
005 06206C06F06306B 01420154015701430153 A7A=A.A8A$ BLOCK 
006 07302006F066020 01630040015701460040 A% 5A.A- 5 S OF 
007 06906E070075074 01510156016001650164 A(A,A#A A" INPUT 
008 02006106E064020 00400141015601440040 5464,49" 5 AND 

009 06F075074070075 01570165016401600165 A.A_A"A#A_ OUTPU 
010 07402006106E064 01640040014101560144 A" 5A6A,A9 T AND 
011 020062065020070 00400142014500400160 5A7A+ 5A# BE P 

012 07206F070065072 01620157016001450162 A3A.A#A+A3 ROPER 
013 06C07902Q065063 01540171004001450143 A=A? 5A+A8 LY EC 
014 06806F06506402E 01500157014501440056 A/A.A+A9 , HOED. 

015 01F000000000000 00370000000000000000 4 


11.41.42.843 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000075 

ABT =02 ADR =0001 ABN =000085 ACT =04 STATUS = 00000000 TLC = 0020 

001 B49390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.41.43.280 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000076 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 11 of 13) 
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RMV2 LOG FILE OUTPUT 
DATE RECORDED - 83/08/05 


83/08/05 
PAGE 00012 


AST =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 
001 830200001001500 40601000000100012400 FCACK P 


11.41.43.284 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000077 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001540 40601000000100012500 FCACK T 


11.42.12.987 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 000078 

ABT =02 ADR =0001 ABN =000000 ACT =03 STATUS = 00000010 TLC = 0037 

001 04E06F077020074 01160157016700400164 ANA.AS 5A" NOW T 

002 06F020074065073 01570040016401450163 A. 5A"A+A% 0 TES 

003 074020074068065 01640040016401500145 A" 5A"A/A+ T THE 

004 02006906E070075 00400151015601600165 5A(A,A#A INPU 

005 07402006306106E 01640040014301410156 A" 5A8A6A7 T CAN 

006 06306506C06906E 01430145015401510156 A8A+A=A(A, CELIN 

007 06702006306F064 01470040014301570144 A* 5A8A.A9 G COD 

008 065040000000000 01450100000000000000 A+A ES 


11.42.13.003 NETPUT (031655) HA =000315 TA =000374 MSG NO. 000079 

ABT =02 ADR =0001 ABN =000086 ACT =04 STATUS = 00000000 TLC = 0020 

001 B49390554B50313 55111620252455201423 INPUT PLS 4 UKP1 

002 000000000000000 00000000000000000000 0 


11.42.14.014 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000080 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001001580 40601000000100012600 FCACK X 


11.42.18.844 NETGETL (031354) ALN =0001 HA =000315 TA =000374 TLMAX =0010 MSG NO. 000081 

ABT =02 ADR =0001 ABN =000000 ACT =03 STATUS = 00000000 TLC = 0006 

001 053048055054044 01230110012501240104 ASAHAUATAD SHUTD 
002 04E000000000000 01160000000000000000 AN N 


11.42.18.860 NETPUT (031655) HA =024544 TA =024545 MSG NO. 000082 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0002 

001 630600001000000 30603000000100000000 CONEND C 

002 2411ADB6DB40000 11010655555555000000 lAF A CH4 


11.42.18.927 NETGETL (031354) ALN =0000 HA =024544 TA =024545 TLMAX =0063 MSG NO. 000083 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


Figure 7-4. Debug Log File Listing for Sample FORTRAN Program (Sheet 12 of 13) 
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RMV2 LOG FILE OUTPUT 

83/08/05 

DATE RECORDED - 83/08/05 

PAGE 00013 

001 634600001000000 30643000000100000000 CONENDN CF 


11.42.26.021 NETOFF (030077) DATE =83/08/05 

MSG NO. 000084 


Figure 7-A. Debug Log File Listing for Sample FORTRAN Program (Sheet 13 of 13);- 


NAH STATISTICS GATHERING STARTED 
NETON DATE 83/08/05. TIME 11.38.26. 

NAM STATISTICS GATHERING TERMINATED 
NETOFF DATE 83/08/05. TIME 11.42.26. 


CPU TIME USED: 


0.244 SEC 


NUMBER OF PROCEDURE CALLS 

NETGET 2 

NET6ETL 46 

NETPUT 34 

NETHAIT 47 

NUMBER OF HORKLIST TRANSFER ATTEMPTS 
SUCCESSFUL 64 

NUMBER OF INPUT/OUTPUT BLOCKS TRANSFERRED 


INPUT 

ABT=0 

2 

INPUT 

ABT=1 

1 

INPUT 

ABT=2 

8 

INPUT 

ABT=3 

37 

OUTPUT 

ABT=1 

11 

OUTPUT 

ABT=2 

11 

OUTPUT 

ABT=3 

12 


NUMBER OF ERRORS 


Figure 7-5. Statistical File Listing for Sample FORTRAN Program 
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The Queued Terminal Record Manager (QTRM) utility 
package allows an application program to use NAM to 
perform Input and output to and from a device or 
application in a way similar to the use of the CYBER 
Record Manager to perform input and output to and 
from mass storage. This section describes the 
interface between QTRM and an application program. 

NAM allows an application program to communicate 
with another application program the same as the 
program does with a device. The program then has a 
connection with a terminal or an application. When 
the term connection is used in this section, it 
refers to the general case and includes both device- 
to-applicatlon connections and application-to- 
applicatlon connections. 

An application program Interface with QTRM has two 
parts: 

A formal data structure, called the network 
information table. Is used as a communication 
area. 

A set of subroutines is used by the application 
program to perform network actions. 


NETWORK INFORMATION TABLE 

An application program uses the network information 
table to communicate with QTRM and with the network 
software through QTRM. The application program 
creates the network information table within its 
own field length. If the program uses overlays, 
the network information table must be created with¬ 
in the main (0, 0 level) overlay. The length of 
the network information table varies according to 
the number of connections the application program 
supports. 

The network information table has the format shown 
in figure 8-1. This table is defined so that its 
first word begins at a word boundary. In a FORTRAN 
program, the table would be created as one or more 
one-dimensional arrays. In a COBOL program, the 
table would be created as a Data Division item 
beginning with an 01 level description, preferably 
in the Working Storage section. 

The network information table has two consecutive 
parts. The first portion is a 10-word entry global 
to program use of the network. The second portion 
consists of 10-word entries unique to each con¬ 
nection serviced by the application program. 

The global portion of the network information table 
contains a few fields that only QTRM writes for the 
application program to read. Most of the fields in 
this portion are read or written by either QTRM or 
the application program. 


The connection portion of the network information 
table contains fields written by QTRM that should 
be used by the application program as read-only 
fields. Errors can result if the application pro¬ 
gram writes in any of these fields. 

The first 9 words of each 10-word entry in the 
second portion of the table are maintained by QTRM 
for each connection. Both QTRM and the application 
program access a given 10-word entry using the 
application connection number assigned by the net¬ 
work to the connection. For example, if a device 
or application is assigned to connection number 3, 
QTRM writes all information concerning that device 
or application into the third iO-word entry in the 
connection portion of the network information table. 
If the application program needs some information 
concerning the device or application assigned to 
connection number 5, it reads the fifth 10-word 
entry in the connection portion of the network 
information table. The connection number assigned 
to the device or application is therefore an index¬ 
ing integer that can be used to access the correct 
10-word entry in the table, or other tables main¬ 
tained by the application program to contain infor¬ 
mation related to servicing the same device or 
application. 

The tenth word of the global portion and the tenth 
word of each of the connection entries are not 
accessed by QTRM. They are reserved for instal¬ 
lation use. 


The application program determines the number of 
10-word entries in the second portion of the net¬ 
work information table. One 10-word entry must 
exist for each device or application the program is 
written to service simultaneously. The application 
program places the number of 10-word entries in the 
first portion of the network information table so 
that QTRM knows how many entries exist. 


The application program does not need to provide a 
10-word entry for each device or application serv¬ 
iced cumulatively during a single program execution. 
The network reassigns a connection number when a 
device or application disconnects from the program, 
so that several devices or applications can sequen¬ 
tially use the same connection number at different 
periods during a single program execution. For 
example, if the program is intended to service eight 
devices at the same time, it provides eight 10-word 
entries. During a single execution, six different 
devices might use each of those entries in succes¬ 
sion, but each device uses only the entry assigned 
to It while it communicates with the program. 
Consequently, the program does not need 48 entries 
to allow for the possibility. 
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net-info-table /Word 


Entry for 
connection 1 


_47_ 35 29 _ 

application-name C(7) 

NAM-supervisor-word 
reserved for CDC 


17 11 5 

T char- num-conns 

set 1(6) 1(12)_ 


parm-addr 

(118) 


Global Entry 
forQTRM { 
communication 


q-data 

i(6) 

parm- 
flag 1(6) 

reserved for CDC 

sub-return 
code 1(12) 

A-to-A 

1(6) 

max-trans-size 
1(12) 

current-trans¬ 
size 1(12) 

sieep 

1(6) 

connection- 
number 1(12) 

return- 
code 1(6 

t 

int-msg 

1(6) 


next-application-name C(7) 
requested-application-name C(7) 


xsleep 1(18) 
destination-host C(3) 


reserved for CDC 

lid c(3) 

reserved for CDC 

reserved for instaliation use 

terminal-name-1/appiication-name-1 C(7) 

tclass-1 

1(6) 

page-width-1 

1(12) 

family-name-1 C(7) 

dev-type 

1(6) 

page-length-1 
1(12) 

user-name-1 C(7) 

sec-lvl-1 

1(6) 

max-block- 

size-l(12) 

abl-1 current-abn-1 acknowledged-abn-1 

1(6) 1(18) 1(18) 

state-1 
1(6) 

In-1 current- 
1(6) abl-l(6) 

reserved for CDC 

sict-1 ict-1 

1(6) 1(6) 


upline-abh-1 
downline-abh-1 
reserved for CDC 
reserved for CDC 
reserved for installation use 


- Read and 
write portion, 
occurs only 
once 


Read-only 
portion, 
repeated once 
for each 
connection 


Entry for 
connection n 
(n=num-conns) 


1 

2 

3 

4 abl-n 


terminal-name-n/appiication-name-n 

family-name-n 

user-name-n 

current-abn-n acknowledged-abn-n 

reserved for CDC 
upline-abh-n 
downline-abh-n 
reserved for CDC 
reserved for CDC 
reserved for instaliation use 


tclass-n 

page-width-n 

dev-type 

1(6) 

page-length-n 

sec-lvl-n 

1(6) 

max-block- 

size-n 

state-n 

In-n 

1(6) 

current- 

abl-n 


sict-n 

1(6) 

ict-n 

1(6) 


tsec-return-code 1(6) 
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net- 1 nfo-tabLe 


application-name 


char-set 


The symbolic address of the entire network information table, used to identify 
the table in a QTOPEN call. In a COBOL program, this address is the Data Divi¬ 
sion descriptor for the level 01 data item containing level 02 or lower level 
data items for all of the fields described in this figure. In a FORTRAN pro¬ 
gram, this address is the name of a one-dimensional array. 

This 42-bit field contains the application name used to identify the program 
to the network, and by other application programs or terminal users to access the 
program. The name contained in this field can be one to seven letters or digits, 
beginning with a letter, and must be left-justified within the field 
and blank-filled to the right; the name must be placed in the field before 
calling QTOPEN. Changing the contents of this field after calling QTOPEN has 
no effect. The name placed in this field is subject to the same restraints 
as the aname parameter in a call to the AIP routine NETON, as described in 
section 5. 

This 6-bit field contains a binary integer to identify the character code set 
and byte packing convention along with the mode of data used by the program 
for all input and output through QTRH. Specify any value from the following 
list; 

1 A 60-bit character is in 60-bit word (allowed only for connections 
to other applications in the same host). 

2 8-bit ASCII codes are packed with 7.5 bytes per 60-bit word (every 
two words contains 15 characters) and transmitted or received in 
normalized mode. 

3 8-bit ASCII codes are packed with 5 bytes per 60-bit word (each char¬ 
acter code is right-justified within a 12-bit byte and zero-filled 

to the left) and transmitted or received in normalized mode. 

4 6-bit display codes are packed with 10 bytes per 60-bit word (this 

is the default value used by QTRM when no other legal value is speci¬ 
fied) . 

10 8-bit codes are packed 7.5 bytes per 60-bit word (every 2 words 
contain 15 characters). Output data is transmitted in transparent 
mode. Input data can be in either normalized or transparent mode. 

11 8-bit codes are packed right-justified with zero fill, 5 bytes per 
60-bit word. Output data is transmitted in transparent mode. Input 
data can be in either normalized or transparent mode. 

The desired code value should be placed in the chai—set field before calling 
QTOPEN. Otherwise, QTRH will assume the character code to be used is 6-bit 
display code and store the default value of 4 in the char-set field. After the 
QTOPEN call, no other QTRH routine will change the contents of this field. If 
the specified value was not 10 or 11, transparent input blocks are automati¬ 
cally discarded by NAH. 

The value initially stored in the char-set field designates the character set 
initially assigned to all connections for input data. However, after QTRM 
informs the application program about a new connection (with a return code 2 or 
14 from a QTGET call), the application program can change the input character 
set before it receives any input on the new connection. The desired character 
set value is stored in this field and QTSUP is called. The input character set 
can be changed as many times as necessary after the connection is established. 

However, there are restrictions for changing the character set values depending 
on the initial value and type of connection that is made. If the character set 
value was set to 1 at QTOPEN time, the following restrictions apply. 

The character set value can be changed only to 2 or 3. 

The application program is restricted to connections only with other appli¬ 
cation programs residing in the same host. 

The input character set for the connection must always match the character 

set of the incoming data. Otherwise, QTRM will terminate the connection. 


Figure 8-1. Network Information Table Format (Sheet 2 of 24) 


60499500 V 


8-3 



If the character set value was set to 4 (display code) at QTOPEN time, the 
application program is normally restricted to only device connections since 
display code is not supported for application-to-application connections. 
However, if the application program has set the A-to-A field to 1 to indicate 
that it supports application-to-application connections, QTRH allows 
application-to-application connections to be established. These connections 
have the initial input character set value set to 2. Data sent and received on 
these connections do not have to be in ASCII. In fact, it should be in display 
code. NAM, however> treats the data as if it were in ASCII. Certain rules 
must be followed by the. application program on these connections. 

For input, aiRM assumes the data received on an application-to-application 
connection is actually display code, even though the ACT field in the ABH 
word says the data is 8-bit ASCII. 9TRM takes the count of 8-bit ASCII 
characters and converts it to a count of display code characters (assuming 
that 1 display code character is equal to 3/4 of an ASCII character). If 
the count of ASCII characters does not convert to a whole number of display 
code characters, 9TRH assumes that the application program sending the data 
is not behaving properly and terminates the connection. The char-set field 
now contains the value 4. 

For output, character set value 4 must be set in the char-set field before 
QTPUT is called. If the current-trans-size field is set, it must be a 
multiple of 4. If the current-trans-size field is zero, the max-trans-size 
field must have a value that is a multiple of 4. 9TRM will not send the 
block if these rules are not followed. Instead, a return code value of 41 
will be stored in the return-code field. 

QTSUP cannot be called to change the character set value on these 
connections. 

The application program at the other end of the application-to-application 
connection should also be-obeying these rules. 

The char-set field is also used to designate the character set for all output 
data. This is done by storing the appropriate value in the char-set field 
before calling QTPUT. This value does not have to match the value for the 
input character set of the connection. 

Use of the default value (display code) for output allows use of QTRH editing 
features. Requirements on the length and contents of the transmitted data are 
described in section 2. 

num-conns This field contains a 12-bit integer, 1 £ num-conns £ 4095, indicating how many 

connections the application program can simultaneously support. Connections 
are assigned numbers from 1 to num-conns; the value used for numconns should 
not be greater than the number of 10-word entries provided in the network 
information table. The network information table must be 10+(10 X num-conns) 
central memory words in length, regardless of whether the program references 
words at the end of the table. The value must be placed in this field before 
the call to QTOPEN. After the call to QTOPEN, changing the contents of the 
field has no effect. 

NAM-supervisor-word This 60-bit field is used by QTRH and should be ignored by the application 

program. The field contains the NETON call nsup parameter used by QTRH. (See 
section 5.) 

parm-addr This 18-bit field contains the symbolic address of a buffer containing data to 

be used in conjunction with calling a particular QTRH routine. Either a binary 
zero or an address must be stored in this field before the call to the QTRH 
routine. A binary zero is stored if the buffer containing data is an optional 
parameter and the application program is not exercising that option. If it is 
not possible for the application program to store an address in this field (for 
example, an application program written entirely in COBOL), QTCHD can be called 
by the application program to set up the addresses in this field of the network 
information table. 


Figure 8-1. Network Information Table Format (Sheet 3 of 24) 
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The following QTRH routines use this field as an input parameter. 

QTENOT If this field is nonzero, it must contain the symbolic address of 

the data to pass to the next application program to receive the 
connection. 

QTLEND If this field is nonzero, it must contain the symbolic address of 
the data to pass to the application program to which the connec¬ 
tion is being loaned. 

QTLINK If the field is nonzero, it must contain the symbolic address of 
any OUTCALL parameters for establishing an appLication-to- 
application connection. The OUTCALL parameters must follow the 
format of the CON/ACRQ/R supervisory message beginning with the 
third word. QTLINK creates the first two words of the supervisory 
message in its own internal buffer. The CON/ACRQ message is 
described in section 3. 

This 6-bit field contains a binary integer that tells QTRM whether the block 
involved in the QTPUT call is part of an X.25 qualified data message. This 
field can contain the following values: 

=0 The downline block is a normal data block. 

^0 The downline block is a qualified data block. 

The connection involved in the current QTPUT call is identified in the 
connection-number field. QTRH uses the q-data field to change the abt field of 
the application block header involved in the QTPUT call. If q-data = 1, abt = 6 
or 7, depending on the value of the int-msg field. 

This 6-bit field contains a binary integer used with different QTRH routines. 
Depending on which QTRH routine is using this field, the field may need to be 
filled before the call to the QTRH routine, or it may contain meaningful 
information after the call to the QTRH routine. 

This field is used as an input parameter by the following QTRH routine: 

QTSUP If called with input parameter smc=H, this field contains the 

input character set value for synchronous supervisory messages if 
the application program wants to change it. The only values 
allowed are 2 or 3. If the application program does not want to 
change the value, either zero or the old value can be stored in 
this field before QTSUP is called. 

If called with input parameter smc=6, this field designates 
whether the application program wants the connection to be 
initially disabled for normal list processing or to be initially 
enabled for list processing. It can have the following values: 

0 The connection is initially enabled for normal list 
processing. 

1 The connection is initially disabled for normal list 
processing. 

If called with input parameter smc=9, this field designates 
whether the host operator can enter another command for this 
application program. It can have the following values: 

0 The host operator cannot enter another command. 

1 The host operator can enter another command. 

If called with input parameter smc=12, this field designates 
whether K-display entries appear in the NAH and system dayfiles. 

It can have the following values: 

0 K-display entries do not appear in the NAH and system 
dayfiles. 

1 K-display entries appear in the NAH and system dayfiles. 
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If called with input parameter smc=13, this field designates 
whether the application-specified-timeout value is a permanent 
change or a one-time change. It can have the following values: 


0 The inactivity timer is reset, for this one-time only, to 
the value specified in the word pointed to by the wsa 
parameter. 

1 The inactivity timer is reset to the value specified in 
the word pointed to by the wsa parameter. All future 
inactivity timeouts are based on this value. 

sub-return-code This 12-bit field contains a binary integer which is the value from the return- 

code field of various supervisory messages. If the application program is 
receiving the supervisory message, this field can contain meaningful information 
after a QTGET call. If the application program is sending a supervisory message, 
this field might need to have the appropriate return code stored in it before 
QTSUP is called. 

The response from a QTGET call results in one of the following values in the 
return-code field: 

rc=6 This field contains the reason code returned in the CON/CB/R 

supervisory message if the sec-return-code field is zero. The 
reason codes for the supervisory messages are explained in 
section 3. 

rc=13 This field contains the reason code returned in the CON/ACRQ/A 

supervisory message. The reason codes for the supervisory messages 
are explained in section 3. 

rc=19 This field contains the contents of the loan-status field of the 

CON/REQ/R supervisory message. The loan-status field is explained 
in section 3. It contains the reason for a loaned connection being 
returned to the original application program. 

rc=20 This field contains the reason code returned in the CON/CB/R super¬ 
visory message. The reason codes for the supervisory messages are 
explained in section 3. 

rc=24 This field contains the reason code returned in the FC/BRK/R super¬ 
visory message. The reason codes for the supervisory messages are 
explained in section 3. 

rc=26 This field contains the reason code or priority data char value 

returned in the INTR/USR/R supervisory message. The reason codes 
for the supervisory messages are explained in section 3. 

rc=34 This field contains the page character from the HOP/PAGE/R super¬ 
visory message. The reason codes for the supervisory messages are 
explained in section 3. 

rc=42 This field contains the contents of the application-specified- 

time-interval flag field from the FC/INACT/R supervisory message. 

The reason codes for the supervisory messages are explained in 
section 3. 

The following calls to QTSUP require the application program to store a return 
code in this field: 

smc=1 This field should be used to store the reason code for the FC/BRK/R 
supervisory message before QTSUP is called. 

smc=4 This field should be used to store the reason code for the 
INTR/APP/R supervisory message before QTSUP is called. 
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A-to-A 


max-trans-size 


This 6-bit field contains an integer indicating whether the application pro¬ 
gram supports application-to-application connections. These application-to- 
application connections may be initiated by this or another application. This 
field can contain the following: 

0 Does not support application-to-application connections. 

1 Supports application-to-application connections. 

The value must be placed in this field before the QTOPEN. After the call to 
QTOPEN, changing the contents of the field has no effect. 

This 12-bit field contains a binary integer that indicates the extent of the 
application program storage area from which data for a connection is sent or 
into which data is written. The value used is specified in units determined 
by the code value that is the char-set value at QTOPEN for input and current 
char-set value for output, as follows: 

If char-set = 1, one max-trans-size unit = 60 bits. 

If char-set = 2 or 10, one max-trans-size unit = 8 bits. 

If char-set = 3 or 11, one max-trans-size unit = 12 bits. 

If char-set = 4, one raax-trans-size unit = 6 bits. 

The value used in this field is subject to the following restrictions; 

Max-trans-size must be less than the number of units that would occupy 410 
central memory words. 

Max-trans-size must be less than 2043 units. 

Max-trans-size must be at least 11 units longer that the value in the 
current-trans-size field, if char-set = 4. 

Max-trans-size must be less than or equal to the number of units that can 
be contained in the text area (working-storage area) used by the program. 

Max-trans-size must be set to a value that can be contained exactly in a 
multiple of central memory words, otherwise QTRM restricts the size of the 
text area without warning the application to make the last character posi¬ 
tion end on a word boundary. 

The value must be placed in this field before any QTPUT or QTGET call, and can 
be changed between calls as appropriate. This field performs a function com¬ 
parable to the tlmax parameter in direct AIP routine calls, as described in 
section 5. 


Current-trans-size 


This 12-bit field contains a, binary integer that indicates how much of the 
application program text area contains data meaningful for a given QTGET, 

QTSUP, QTLEND, QTLINK, QTENDT, or QTPUT call. The value used is specified in 
units determined by the code value that is the current char-set value for the 
connection or the charset value for the particular output block for QTGET and 
QTPUT calls, as follows; 

If char-set = 1, one current-trans-size unit = 60 bits. 

If char-set = 2 or 10, one current-trans-size unit = 8 bits. 

If char-set = 3 or 11, one current-trans-size unit = 12 bits. 

If chai set = 4, one current-trans-size unit = 6 bits. 

For QTLINK, QTSUP, QTLEND, and QTENDT calls, the value must always be specified 
as the number of complete or partial central memory words and it indicates how 
much of the buffer area pointed to by parm-addr contains meaningful data. 
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On return from a QTGET call that delivers a data block to the program, QTRM 
places a value in this field that indicates the size of the delivered block. 
Before a QTPUT call, the application program must set a value in this field 
that indicates to QTRM the size of the block to be transferred. For char-set 
values other than 4, the application program must indicate how many units com¬ 
prise the block (including all ASCII unit separator character codes and any 
format effector characters). For a char-set value of 4, the application pro¬ 
gram can use a value of 0, or the nonzero value indicating how many units com¬ 
prise the block (including all zero byte separators except the last and all 
format effector characters). Special QTRM output editing functions are per¬ 
formed for data blocks with a char-set of 4, depending on the value in the 
current-trans-size field; these functions are described in the text under the 
heading Display-Code Output Editing. Current-trans-size must be less than or 
equal to max-trans-size. 

sleep This 6-bit field contains a signed integer that tells QTRM what action to take 

after the application program issues a QTGET call. (See also the XSLEEP 
field.) This field can have the values: 

-n Where 1 £ n < 32; if no data block or return-code field value other 

than 1 is available to return, the program is suspended by QTRM 
until information becomes available. If information is available, 
control returns to the program immediately. The value used for n is 
not significant. 

0 Interrogate XSLEEP to determine what action to take after QTGET is 

issued. 

+n Where 1 £ n < 32; the program will be suspended for a maximum of n 

seconds. Control is returned to the program as soon as any infor¬ 
mation is available (the return-code field value is not 1) or when 
the current-abl-i field value is increased for any connection (the 
return-code field value is 1). If no information is available after 
n seconds, control is returned to the program with a reason-code 
field value of 1. 

The application program must set or change the value in this field as neces¬ 
sary before each QTGET call. QTRM does not change the value in this field 
after QTOPEN has been called. (QTOPEN sets the field to zero.) 

connection-number This 12-bit field contains an integer that identifies the connection involved 

in the current QTGET, QTPUT, QTTIP, QTLEND, QTSUP, or QTENDT call. On return 
from a QTGET call, QTRM places the connection number in this field for the 
connection for which information was returned by the call. If the application 
program uses the option to selectively poll connections for data (option chosen 
through QTCHD with cc=8), the application program should store the connection 
number of the connection it would like to receive data from in this field. If 
zero is stored in this field, QTRM fetches and processes only asynchronous 
supervisory messages. If the application does not use the option that selec¬ 
tively polls connections for data, this field has no meaning before the QTGET 
call. Before a QTPUT, QTTIP, QTLEND, QTSUP, or QTENDT call, the application 
program must place the connection number in this field for the connection 
involved in the call. This value can be used as a subscriptor or index value 
to access the corresponding 10-word connection entry in the network information 
table. 


Figure 8-1. Network Information Table Format (Sheet 7 of 24) 


8-8 


60499500 V 



return-code 


This 6-bit field is used by QTRH to indicate program or connection processing 
status on return from a QTOPEN, QTGET, 9TEN0T, aTTIP, QTLEND, QTSUP, QTCMO, 

QTPUT, or QTLINK call. The application program should always test the contents 
of this field after a QTOPEN (if OTCMD was called with cc=9), QTGET, QTENDT, 
QTTIP, QTLEND, QTSUP, QTCHD, QTPUT, or QTLINK call. This field can contain the 
following values: 

0 Information has been exchanged with the network. After a QTGET, 

this value indicates that a block was received from a connection and 
is in the application program text input area identified for that 
QTGET call; the connection number of the connection generating the 
block is in the connection-number field. After a QTPUT, this value 
indicates that the block was given to NAM (however, the block might 
not have been delivered to the connection yet). 

After a QTOPEN call is made by the program, this value indicates 
that the application program is connected to the network. 

After a QTLINK call has been made by the program, this value indi¬ 
cates that the request for connection to an application is being 
forwarded to NAM and is outstanding. 

After a QTLEND call has been made by the program, this value indi¬ 
cates that the request for loaning the connection was forwarded to 
NAM. 

After a QTSUP call has been made by the program, this value indi¬ 
cates that the supervisory message was created and sent to NAM. 

After a QTCMD call has been made by the program, this value indi¬ 
cates that QTRM has made the change in the way it executes. 

After a QTENDT call has been made by the program, this value indi¬ 
cates that QTRH has terminated the connection. 

After a QTTIP call has been made by the program, this value indi¬ 
cates that the synchronous supervisory message was sent to NAM. 

1 No information has been exchanged with the network. This value only 
occurs after a QTGET call that was made while the sleep or xsleep 
field contained 0 or a positive value. 

2 A new device or application connection has occurred. This value 
only occurs after a QTGET call. The connection number of the new 
connection is in the connection-number field, but no data block has 
been returned by the QTGET call; the 10-word entry in the network 
information table has been updated by QTRM for the new connection. 

3 Reserved for CDC use. 
and 

4 

5 The application program has made an invalid call to QTPUT or QTTIP. 
This value occurs only in response to a QTPUT or QTTIP call. The 
sec-return-code field contains the reason QTPUT rejected the call.' 
The data block involved in the call was not sent. 


Figure 8-1. Network Information Table Format (Sheet 8 of 24) 


60499500 V 


8-9 
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The connection between NAM and the device or application program 
identified in the connection-number field has been broken. This 
value occurs only in response to a QTGET call. This could be due 
to either QTRH terminating the connection or the network informing 
QTRH that the connection was broken. If (JTRM terminated the 
connection, the reason for the termination will be stored in the 
sec-return-code field. This could have been due to one of the 
following conditions: 

A block sent to the device or connection might have been lost 
by the network. 

A block from the device or application program was too large 
to deliver and the application program did not request data 
truncation for data blocks on that connection. 

A block from the device or application program could not be 
delivered because the block was of a character type that QTRH 
could not receive. 

A block from an application program could not be delivered 
because the block was of the wrong size for display code data. 

If the sec-return-code field is zero, the network informed QTRH 
that the connection was broken. This could have been due to one of 
the following conditions: 

The terminal user hung up. 

The communication line failed. 

The other application program failed, stopped running, or 
terminated the connection. 

The reason code from the CON/CS/R supervisory message is stored in 
the sub-return-code field. 

No additional communication is possible between the application 
program and that device or application, and QTENDT should not be 
called. The information in the 10-word entry for the affected con¬ 
nection remains unchanged until a new connection is made that uses 
the same entry. 

7 The user at the terminal identified in the connection-number field 
has entered a user-break-1 character or caused a user-break-1 
condition. This value only occurs after a QTGET call. On return 
from the call, QTRH has reset the current-abl field for the affected 
device to the value in the device abl field; this change indicates 
that any blocks previously sent by the program but not yet delivered 
to the device were discarded. The action taken by the application 
program is determined by what the terminal user expects to occur 
after entry of the character. 

8 The user at the terminal identified in the connection-number field 

■ has entered a usei—break-2 character. This value only occurs after 
a QTGET call. On return from the call, QTRH has reset the 
current-abl field for the affected device to the value in the device 
abl field; this change indicates that any blocks previously sent by 
the program but not yet delivered to the device were discarded. The 
action taken by the application program is determined solely by what 
the terminal user expects to occur after entry of the character. 

9 The network is shutting down. All terminal users should be notified 
and QTCLOSE should be called as soon as no data blocks are outstand¬ 
ing in either direction. 

10 The network has ended all communication with the application pro¬ 
gram. This value only occurs after a QTGET call; normally, this 
value means that the application program should close all files and 
end its execution. No calls to QTRH routines can be made after re¬ 
ceipt of this reason-code value; a call to QTCLOSE is not necessary. 


Figure 8-1. Network Information Table Format (Sheet 9 of 24) 


8-10 


60499500 V 



11 


Figure 


The application program has performed some operation that violates 
NAM protocols. QTRM has received a logical error supervisory mes¬ 
sage from NAM, as described in section 3. QTRM places the reason 
code from the supervisory message in the sec-return-code field of 
the network information table. Unless QTCHD was called with cc=10, 
QTRM will abort the application program. 

12 The application program has made an invalid call to QTLINK. This 
value occurs only in response to a QTLINK call. The sec-return-code 
field contains the reason QTLINK rejected the call. No application 
connection request was initiated. 

13 The connection was not established. This value is returned by a 
QTGET call issued by the program following a QTLINK request. The 
sec-return-code field contains one of the following: 

The rc2 field from the abnormal response to the request-for- 
connection supervisory message (CON/ACRQ/A) issued by QTRM 

The reason code plus 32 from the connection-broken supervisory 
message (CON/CB/R) if the connection was broken before the 
connection-processing was completed 

The reason codes for these supervisory messages are explained in 
section 3. 

14 The application-to-application connection is completed. This value 
is returned by a QTGET call issued by the program following a QTLINK 
request. The connection-number field contains the new connection 
number. The 10-word entry in the network information table has been 
updated with the new connection information. 

15 The connection specified in the connection-number field cannot be 
loaned to another application program at this time. Either: 

A break condition is outstanding. 

An interrupt condition is outstanding. 

Unacknowledged blocks are outstanding. 

The connection does not exist. 

The connection is not yet ready for data traffic. 

The connection is not to a device. 

The connection is already a loaned connection. 

This value occurs only in response to a QTLEND call. The appli¬ 
cation program still has the connection. The application program 
can check the sec-return-code field to determine the reason QTLENO 
rejected the request. 

16 The application program has made an invalid call to QTGET. This 
value occurs only in response to a QTGET call and only when the 
application program previously called QTCMD to select connection 
polling for data. The sec-return-code field contains the reason 
code indicating why QTGET rejected the call. No asynchronous 
supervisory messages or data was retrieved. 

17 Reserved for CDC use. 

18 A device connection previously loaned to another application pro¬ 
gram has been returned to this application program. The connection 
number in the connection-number field identifies the loaned connec¬ 
tion. This value occurs only in response to a QTGET call, and only 
if QTLEND was previously called to loan this connection to another 
application program and QTLENO accepted the connection loan request. 
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19 The application program has reconnected with the connection indi¬ 
cated in the connection-number field. This value occurs only after 
a QTGET. call, and only if QTLEND was previously called for this 
connection and accepted the connection loan request. Also, QTCMD 
must have previously been called to request notification of initial 
connection requests. The connection is not yet ready for data 
traffic. Data traffic is allowed after the application program 
receives a return code of 18 for this connection after a QTGET 
call. The sub-return-code field indicates whether the connection 
was returned normally or abnormally. If the current-trans-size 
field is nonzero, data has been passed to this application program 
from the application program to which the connection was loaned. 

The data was written to the application program text input area 
identified for that GTGET call. The data is truncated if not all 
the passed data can fit in the text input area. The current-trans- 
size field contains the number of words of passed data copied to the 
text input area. 

20 The connection identified in the connection-number field that this 
application program loaned to another application program was broken 
by one of the following conditions: 

The terminal user hung up. 

The communication line failed. 

The application program that the connection was loaned to 

aborted the connection. 

This value occurs only after a QTGET call. The sub-return-code 
field contains the reason code from the COM/CB/R supervisory 
message. No additional communication is possible between the appli¬ 
cation program and that device. QTENOT must not be called. The 
information in the 10-word entry for the affected connection remains 
unchanged until a new connection is made which uses the same entry. 

21 The application program has just received a connection request. 

This value occurs only after a QTGET call and only if the appli¬ 
cation program previously called QTCMD to request notification of 
the initial connection request. The connection number of the new 
connection is in the connection-number field. The 10-word entry in 
the network information table has been updated by QTRM for the new 
connection. However, the connection is not yet ready for data 
traffic. Data traffic is allowed only after the application pro¬ 
gram receives a return code 2 or 14 for this connection after a 
QTGET call. If the current-trans-size field is nonzero, data has 
been passed to this application program from the last application 
program to which this connection (which must be a device connection) 
was connected. The data has been written to the application program 
text input area identified for that QTGET call. If all of the 
passed data is unable to fit in the text input area, the data is 
truncated. The current-trans-size field contains the number of 
words of passed data copied to the text input area. 

22 The application program has made an invalid call to QTENDT. This 
value occurs only in response to a QTENDT call. The sec-return-code 
field contains the reason QTENDT rejected the call. No connection 
was terminated. 

23 The application program has caused a screen formatting error. This 
is usually caused by an error on the part of the terminal user 
entering data. 

24 The application program has received a break indication (FC/BRK/R 
supervisory message) on the connection identified in the connection- 
number field. This value occurs only after a QTGET call and only 
for an application-to-application connection. The network does not 
require any action or response from the application program. QTRM 
sends the reset response <FC/RST/R supervisory message) for the 
break condition. The sub-return-code field contains the reason code 
for the break condition. 
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The application program has received the reset response from the 
network for the connection identified in the connection-number 
field. This value occurs only after a QTGET call and only for a 
connection that was in a break condition. The break condition 
exists only after the application program has called QTSUP to send 
a break condition to the other end of the connection. The applica¬ 
tion program can now call QTSUP to send another break condition for 
this connection. 

26 The application program has received a priority data message 
(INTR/USR/R supervisory message with reason code other than user 
break 1 or 2) on the connection identified in the connection-number 
field. This value occurs only after a QTGET call and only if the 
application program called QTCMD to request notification of user 
interrupts. The network does not require any action or response 
from the application program. QTRM sends the user acknowledgment 
CINTR/RSP/N supervisory message) for the interrupt connection. The 
sub-return-code field contains the reason code for the interrupt 
condition. 

27 The application program has received the user interrupt response 
(INTR/RSP/R supervisory message) on the connection identified in 
the connection-nimber field. This value occurs only after a QTGET 
call and only if the application program called QTSUP to send a 
user interrupt to the other end of the connection. The network 
does not require any action or response from the application pro¬ 
gram. The application program can now call QTSUP to send another 
user interrupt for this connection. 

28 The application program has received the user break marker 
(BI/MARK/R supervisory message) on the connection identified in 
the connection-number field. This value occurs only after a QTGET 
call and only if the application program previously called QTCHO to 
indicate that it wanted to be informed about the user break marker. 
The connection involved is always a device connection in a user 
break condition (return code 7 or 8 response for this connection in 
a previous QTGET call). The application program must call QTTIP to 
send a RO/HARK/R synchronous supervisory message before any more 
downline data will be delivered to the device. After receiving this 
return code, the application program assumes that any new data it 
receives on the connnection was entered after the user break. 

29 The application program has received a synchronous supervisory 
message other than BI/HARK/R (user break mark) on the connection 
identified in the connection-number field. This value occurs only 
after a QTGET call. The connection involved is always a device 
connection. The synchronous supervisory message is in the 
application program text input area identified for the QTGET call; 
the message originates from either CCP or CDCNET. The network does 
not require any action or response from the application program. 

30 Reserved for CDC use. 

31 The host operator has assigned the NAM K-display to this applica¬ 
tion program. This value occurs only after a QTGET call when the 
application program has previously called QTCMD to inform QTRM that 
it supports the NAM K-display. If the text input area is at least 
one word long, QTRM stores the length of the left and right screens 
in the first word of the text input area. This first word is 
actually the first word of the HOP/START/R supervisory message. 

The format of this message is described in section 3. If the text 
input area is not large enough, the information on the size of the 
left and right screens is lost. 

Upon receipt of this return code, the application program should 
generate a banner or other display data and call QTSUP to send the 
display data to NAM. 
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Figure 


32 The host operator has entered a K-display typein. This value 
occurs only after a QTGET call when the application program has 
been'assigned the NAH K-display (return code 31 was received after 
a QTGET call). QTRM writes the operator typein to the application 

^ program text input area identified for that QTGET call. If the 
text input area is not large enought to contain the operator typein, 
QTRM truncates the typein and the last part of the typein is lost. 
The current-trans-size field contains the number of characters (in 
display code only) of the operator typein written to the text input 
area. Until the application program sends display data back to NAM 
with the input-allowed flag set (QTSUP call with parra-flagi set to 
1), the host operator cannot enter any more NAH K-display typeins 
for this application program. 

33 The host operator has entered the break character. This value 
occurs only after a QTGET call and the application program has been 
assigned the NAH K-display (return code 31 was received after a 
QTGET call). The operator is probably no longer interested in data 
from this application program and wants to enter another typein. 

The application program should call QTSUP to send a HOP/DIS/R 
supervisory message to NAM with the input-allowed flag set (parm- 
flagl set to 1 for the QTSUP call). No K-display data is necessary 
for this call (current-trans-size field is set to zero). 

34 The host operator has entered a page character. This value occurs 
only after a QTGET call when the application program has been 
assigned the NAM K-display (return code 31 was received after a 
QTGET call). Because the host console can display only a finite 
number of lines of data, NAH scrolls the oldest data off the top of 
the screen. The newest data always appears at the bottom of the 
screen. If the application program sends more than one screen of 
display data, only the last part of the data remains on the screen. 
This may or may not be desired by the operator. The page character 
allows the operator to inform the application program whether it 
should send all the display data at once or only one screen at a 
time. 

There are four page characters: the plus (+) character, the minus 
(-) character, the left parenthesis (() character, and the right 
parenthesis ()) character. The plus and minus characters control 
paging of the left screen. The left and right parenthesis 
characters control paging of the right screen. 

If the page character is the plus character, the operator is 
requesting the application program to page the left screen 
display data one screen at a time. 

If the page character is the minus character, the operator is 
requesting the application program not to page the left screen 
display data. 

If the page character is the left parenthesis character, the 
operator is requesting the next page of the right screen 
display data. 

If the page character is the right parenthesis character, the 
operator is requesting the previous page of the right screen 
display data. 

For the left screen, the convention is that all application programs 
should assume that paging is off when the operator assigns the 
K-display to them. The application program should never send more 
than one screen full of display data to the left screen at one 
time. If the application program has more than one screen to send, 
it must wait for another plus page character before sending the next 
screen (after a QTGET call, the application program must receive 
another return code 34 with the page character set to the plus 
character). This interaction between the operator and the 
application program can be repeated until the application program 
has no more data to display or the operator enters another command. 
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For the right screen, the convention is that paging is always on. 

The application program should never send more than one screen full 
of display data to the right screen. 


The page character is in the sub-return-code field and is always 
either the plus, minus, left parenthesis, or right parenthesis 
character in display code. If the application program was not 
designed to handle paging, it can choose to ignore this return code. 

35 

The NAM K-display is no longer assigned to this application 
program. This value occurs only after a 9TGET call when the appli¬ 
cation program has been assigned the NAM K-display (return code 31 
was received after a QTGET call). 

36 

The host operator has entered a request for this application pro¬ 
gram to dump its field length. This value occurs only after a QTGET 
call. The application program can ignore this request, call QTDM8 
to perform a binary dump, or perform its own field length dump. 

37 

The host operator has entered a request for this application program 
to turn on its debug code. This value occurs only after a QTGET 
call. The application program can ignore this request. 

38 

The host operator has entered a request for this application program 
to turn off its debug code. This value occurs only after a QTGET 
call. The application program can ignore this request. 

39 

The host operator has entered a request for this application pro¬ 
gram to reset its statistical counters. This value occurs only 
after a QTGET call. The application program can ignore this request 
or call QTSTC to reset AIP's statistical counters and reset its own 
statistical counters, if it has any. 

40 

The host operator has entered a request for this application pro¬ 
gram to flush the AIP debug log file. This value occurs only after 
a QTGET call. The application program can ignore this request or 
call QTREL to release the AIP debug log file. QTREL should be 
called only when the application program has been designed to call 
it and has already called QTREL before calling QTOPEN. 

41 

The QTOPEN request did not complete successfully. This can occur 
only after a QTOPEN call and only if QTCMD is called with cc=9 
before the QTOPEN call. The sec-return-code field of the network 
information table contains a reason code indicating why the QTOPEN 
request failed. 

42 

The connection indicated in the connection-number field has been 
inactive for an installation defined time interval. This value 
occurs only in response to a QTGET call and only when the applica¬ 
tion program has previously called QTCMD to inform QTRH that it 
wants to be informed about inactive connections. The sub-return- 
code field contains the value of the application-specified-time- 
interval flag field from the FC/INACT/R supervisory message. If 
the installation or application program has not set this time 
interval, the default value is 10 minutes. 

43 

The application.program has made an invalid call to QTCMD. This 
value occurs only in response to a QTCMD call. The sec-return-code 
field contains the reason QTCMD rejected the call. No change 
occurred in QTRH processing. 

44 

The application program has made an invalid call to QTSUP. This 
value occurs only in response to a QTCMD call. The sec-return-code 
field contains the reason QTSUP rejected the call. No supervisory 
message was sent to NAM. 

45 

thru 

62 

Reserved for CDC use. 
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63 An internal or uncoded error. If this happens, it means something 
severe has taken place in QTRM. You should close your files, abort 
your program, and do a dump. 

sec-return-code This 6-bit field contains a binary integer indicating the cause of an error in 

the network or application program. This field is used by different QTRH rou¬ 
tines, always in conjunction with a nonzero value in the return-code (rc) field. 

The following QTRH routines store a meaningful value in the sec-return-code 
field when-the return-code field has the designated values: 

QTCMD» rc=43 This field contains the reason QTCHD rejected the 

command request. It can have the following value: 

1 The command code was unrecognized by QTCMD. 

QTENDT rc=22 This field contains the reason QTENDT rejected the 

request to terminate the connection. It can have one 
of the following values: 

4 The connection number in the connection-number 
field was for a nonexisting connection. 

6 The application program set the parm-addr field 
in the network information table to indicate 
that data was to be passed on to the applica¬ 
tion program designated in the next-application 
field or to the application program that loaned 
the connection to this application program, if 
this was a loaned connection. However, the 
current-trans-size field contained the value 
zero so that QTENDT could not determine how 
much data to pass. 

15 The application program set the parm-addr field 
in the network information table to indicate 
that data was to be passed to the application 
program designated in the next-application 
field or to the application program that loaned 
the connection to this application program, if 
this was a loaned connection. However, the 
current-trans-size field contained a value 
larger than the maximum amount of data that can 
be passed to the next application program 
(greater than 52 words). 

18 The connection number designated in the 

connection-number field belongs to a device 
connection that was loaned to another applica¬ 
tion program. The connection cannot be termi¬ 
nated until the device is reconnected with this 
application program. 

QTGET rc=6 This field contains the reason QTRH terminated the 

connection. It can have one of the following values: 

22 An FC/NAK/R supervisory message was received on 
this connection; at least one data block sent 
on this connection may have been lost. 

23 QTRH could not receive a data block on this 
connection; the ibu bit was set in the applica¬ 
tion block header word. 
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24 

QTRM could not deliver a data block to the 
application program on this connection because 
the block was the wrong size. The connection 
is an application-to-application connection in 
which the application program is receiving all 
data in display code. This requires the 
incoming block to have a size count which is a 
multiple of 3 (a whole number of display code 
characters in the block). 


rc=11 

This field contains one of the integer logical-error 
supervisory message codes described in section 3. 


rc=13 

This field contains the value of subfield rc2 if the 
return code was caused by aTRM receiving a CON/ACRQ/A 
supervisory message or the value of the reason code 
plus 32 if the return code was caused by QTRM receiving 
a CON/CB/R supervisory message in response to a QTLINK 
request. 


rc=16 

This field specifies the reason QTGET rejected the 
command request. It can have the following values: 



4 

The connection number designated in the 
connection-number field was for a nonexisting 
connection. 



18 

The connection number designated in the 
connection-number field belongs to a device 
connection previously loaned to another appli¬ 
cation program. No data can be obtained from 
the connection until the connection number is 
returned to this application. 

QTLEND 

rc=15 

This field contains the reason QTLEND rejected the 
request to loan the connection to the other application 
program. It can have one of the following values: 



2 

The connection is already a loaned connection 
from another application program. 



4 

The connection number in the connection-number 
field was for a nonexisting connection. 



6 

The application program set the parra-addr field 
in the network information table to indicate 
that data was to be passed on to the applica¬ 
tion program designated in the next-application 
field. However, the current-trans-size field 
contained the value zero so QTLEND could not 
determine how much data to send. 



12 

The connection number is not a device connec¬ 
tion; it is an application-to-application 
connection. 



13 

The connection has downline blocks outstand¬ 
ing. The application program must wait for the 
current-abl field value for the connection to 
equal the abl field value for the connection. 



14 

No application program was specified for Loan¬ 
ing the connection to; the next-appLication- 
name field contained zero. 
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15 

The application program set the parm-addr field 
in the network information table to indicate 
that data was to be passed to the application 
program designated in the next-application 
field. However, the current-trans-size field 
contained a value larger than the maximum 
amount of data that can be passed to another 
application program (greater than 52 words) so 
that QTLEND could not determine how much data 
to pass. 



18 

The connection number specified in the 
connection-number field belongs to a device 
connection Loaned to another application 
program. The connection cannot be Loaned to 
another application program until the device 
is reconnected with this application program. 

QTLINK 

rc=12 

This field contains the reason QTLINK rejected the 
request to initiate an application-to-application 
connection. It can have one of the following values: 



6 

The size of the OUTCALL data parameters was 
zero. The application program set the 
parm-addr field to nonzero (indicating it had 
OUTCALL data), but the current-trans-size field 
was zero. 



15 

The size of the OUTCALL data parameters was too 
Large; the application program had set the 
parm-addr field to nonzero to indicate that it 
had OUTCALL data, but the current trans-size 
field contained a value greater than 52 words. 



19 

There is a previous QTLINK Link request 
outstanding. No new QTLINK request can be 
honored until processing is completed on the 
previous request. 

QTOPEN 

rc=41 

This field contains the reason QTOPEN rejected the 
call. It can contain the status code from a rejected 

NETON request (see figure 5-1 in section 5 for values) 
or one of the following values: 



25 

The application program called QTOPEN a 
second time after a previous call completed 
successfully. 



26 

The maximum number of connections specified in 
the network information table was zero. 

QTPUT 

rc=5 

This field contains the reason QTPUT rejected the 
request to send an output block to the network. It can 
have one of the following values: 



3 

The output could not be sent because the 
connection is not in a state that allows out¬ 
put to be sent on the connection. 



4 

The connection-number in the connection-number 
field was for a nonexisting connection. 



18 

The connection number designated in the 
connection-number field belongs to a device 
connection that was loaned to another applica¬ 
tion program. Output cannot be sent to the 
device until after the device is reconnected 
with this application program. 
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20 

The application program attempted to send 
display code output on an appLication-to- 
application connection and either specified a 
size in the current-trans-size field that was 
not a multiple of 4 or the max-trans-size field 
was not a multiple of 4. 



21 

The application program had already reached its 
application block limit. The current-abl field 
contains zero and the application program 
attempted to send another block. This is not 
allowed until at least one of the outstanding 
blocks is acknowledged (until the current-abl 
field is set to nonzero by QTRM). 

QTTIP 

rc=5 

This field contains the reason QTTIP rejected the 
request to send an synchronous supervisory message to 
the network. It can have the following values: 



3 

The synchronous supervisory message could not 
be sent because the connection is not in a 
state that allows synchronous supervisory 
messages to be sent. 



4 

The connection number in the connection-number 
field was for a nonexisting connection. 



18 

The connection number in the connection-number 
field belongs to a device connection that was 
loaned to another application program. 

Synchronous supervisory messages cannot be 
sent to the device until after the device is 
reconnected with this application program. 



21 

The application program had already reached its 
application block limit. The current-abl field 
contains zero and the application program 
attempted to send another block. This is not 
allowed until at least one of the outstanding 
blocks is acknowledged (until the current-abl 
field is set to nonzero by QTRM). 

QTSUP 

rc=44 

This field contains the reason QTSUP rejected the 
request to send an asynchronous supervisory message to 

NAM. It can have one of the following values: 



1 

The supervisory message code was an invalid_ 
value. 



3 

The supervisory message could not be processed 
because the connection is not in the normal 
state (state field did not contain 2). 



4 

The connection number in the connection-number 
field was for a nonexisting connection. 



6 

The size-of the supervisory message was not 
specified for smc = 0, 9 , or 10. The 
current-trans-size field contained zero. 



7 

The input character set value specified for 
smc.=2 was not a valid value for data. Valid 
values are in the range 1 to 4 and 10 or 11. 
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8 The connection number specified in the 
connection-number field is for a connection 
which will not allow the QTSUP call with 
supervisory message code 2. The application 
program cannot change the input character type 
of the connection because the connection is an 
application-to-application connection and the 
initial input character type specified for the 
connection was display code. 

9 The input character set value specified for 
smc = 2 in the parm-flagi field was not a valid 
value for synchronous supervisory messages. 
Valid values are 2 or 3. 

10 The value specified in the parm-flagi field for 
smc = 6 was not a valid value. Valid values 
are 1 or 0. 

11 The value specified in the parm-flagi field for 
smc = 9 was not a valid value. Valid values 
are 1 or 0. 

15 The value specified in the current-trans-size 
field for smc = 0, 9, or 10 was too large. If 
the smc was 0 or 9, the value was greater than 
410 words; if the smc was 10, the value was 
greater than 8. 

16 The K-display is not assigned to this appli¬ 
cation program. The supervisory message 
should be sent only when the NAM K-display 
is assigned to the application program. 

17 The application program has not notified 9TRM 
(by calling QTCHD) that it supports the NAM 
K-display. The supervisory message cannot be 
sent until that is done. 

18 The connection number designated in the 
connection-number field belongs to a device 
connection that was loaned to another appli¬ 
cation program. No supervisory message can be 
sent for that connection until the device is 
reconnected with this application program. 

int-msg This 6-bit field contains an integer that indicates to QTRH whether the block 

involved in a QTPUT call is or is not the last or only block of a message. If 
the application program supports terminals in terminal class 4, this field 
must be written before any QTPUT call. Programs supporting application-to- 
application connections can also use this field but it only has significance 
to the destination application. This field can contain the following values: 

0 The last or only block of the message. The application program will 
not call QTPUT again for the current connection until a QT6ET call 
has returned an input block. 

1 An intermediate block in a multiple block message. The application 
program will call QTPUT again for the current connection before a 
call to QT6ET has returned an input block from that connection. 

The connection involved in the current QTPUT call is identified in the 
connection-number field. QTRH uses the int-msg field to change the abt field 
of the application block header involved in the QTPUT call. 

If int-msg = 0 and q-data = 0, then abt = 2. 

If int-msg = 1 and q-data = 0, then abt =1. 

If int-msg = 0 and q-data = 1, then abt = 7. 

If int-msg = 1 and q-data = 1, then abt = 6. 
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next-appLication-name This 42-bit character data field contains the network application program name 

identifying the program to which a device should be switched to during processing 
of a QTENOT call or loaned to during processing of a QTLEND call. This field can 
contain the following: 

0 The network software uses prompting dialog or automatic login 

information to determine the next application program the device 
communicates with, or disconnects the device from the host if 
that is an appropriate action. 

NVF The Network Validation Facility reinitiates the login sequence 

command for the device or causes terminal disconnection from the host. 

ABORT This word is valid as a next-application-name only if the 

connection is a loaned connection. The connection is not 
returned to the primary application. Instead, the terminal 
user is prompted for a new application to connect to. 

valid The device is switched or loaned to the indicated program without 

program prompting dialog, when the switch is possible. 


If the NVF command, valid program name option, or ABORT is used, the name placed 
in the field must be one to seven display code letters or digits, left-justified 
with blank fill within the field, and the first character must be alphabetic. 

If the NVF command option is used, the following .commands are valid: 

Cause the device to be disconnected from the host. 

HELLO \ Reinitiate login for the device; if dialog is possible and 

LOGIN ) required, the login prompting sequence begins. 

If the valid program name option is used, the name placed in the field must be 
the element name used to define the referenced application program in the sys¬ 
tem common deck COHTNAP. 

For an application-to-application connection, this afield must contain a 0. 

The QTOPEN call sets this field to zero. The application program must set or 
change this field as appropriate before each QTENOT call. Guidelines for the 
use of this field can be found under Terminating Connections in section 3. 

This field is not used with QTENOT calls for application-to-application 
connections. 

xsleep This 18-bit field contains a signed integer that tells QTRH what action to 

take after the application program issues a QTGET call.- (See also the SLEEP 
field.) This field can have the values: 

-n Where 1 £ n < 4096; if no data block or return-code field value other 
than 1 is available to return, the program is suspended by QTRH until 
information becomes available. If information is available, control 
returns to the program immediately. The value used for n is not 
significant. 

0 The QTGET call is not associated with program suspension; if no data 
block is available, control returns to the program immediately and a 
return-code field value of 1 is used to indicate the condition to the 
program. If a block is available, control- also returns to the program 
immediately. 

+n Where 1 £ n < 4096; the program will be suspended for a maximum of n 
seconds. Control is returned to the program as soon as any infor¬ 
mation is available (the return-code field value is not 1) or when 
the current-abl-i field value is increased for any connection (the 
return-code field value is 1). If no information is available after 
n seconds, control is returned to the program with a reason-code 
field value of 1. 
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requested-appUcation- This 42-bit character data field contains the network application program name 

name identifying the program to which the current application program is requesting 

a connection with a QTLINK call. This is the first identifier for the 
connection. This identifier can be one to seven letters or digits long and is 
left-justified with blank fill within this field; the first character must be a 
letter. For intra-host connections, this field contains the name of the 
application program with which your program needs to establish a connection. 

For inter-host connections, the name you use must match .the value of the NAMEI 
parameter in the NDL OUTCALL statement used by your program. 

destination-host This 18-bit character data field contains the second identifier for a connec¬ 

tion your program initiates with a QTLINK call. If the connection is between two 
hosts, this identifier must be one to three letters or digits, left-justified 
with blank fill within the field; the first character must be a letter. If the 
connection is within a host, this identifier can be a binary 0. By convention, 
any nonzero name is the name of the destination host in which the other 
application program runs. The name you use must match the value of the NAME2 
parameter in the NDL OUTCALL statement used by your program. 

trunc This 6-bit field contains a binary integer identifying if the data in the text 

input area is the complete data block received by QTRM or if the data has been 
truncated. This field has meaning only after a QTGET call which results in data 
being written to the text input area. The data could be either from a super¬ 
visory message or from a connection. For data from a connection to be truncated, 
the application program must have previously called QTSUP to truncate upline 
data blocks which are too large for the text input area. Data from supervisory 
messages is always truncated if it is too large for the text input area. This 
field can have the following values: 

0 The data in the text input area is complete. No truncation occurred. 

1 The data in the text input area is not the complete data that was 

received. The last part of the data was lost due to the truncation. 

lid This IS-bit character data field contains the logical identifier of the host of 

the program that this application program is initiating a connection to with a 
QTLINK call. It is an optional parameter, but at least one of the parameters 
lid/destination host must be specified for interhost connections. If the lid 
parameter is not specified or is an intrahost connection request, a binary zero 
should be stored in the field. 

If a logical identifier is specified, that lid should have been previously 
specified in the LIDCMid file. (See the NOS Installation Handbook). If a lid 
is specified and a destination host is not specified, a physical identifier (pid) 
associated with that lid will be used to match the value of the pid parameter in 
the NDL OUTCALL statement. 

If both the lid and destination host are specified, the destination host is 
assumed to be a pid, and must have been previously specified as a valid pid for 
the lid in the LIDCMid file. 

This 42-bit character data field contains the display code characters of the 
name used to identify the device on connection i within the network. The name 
is one to seven letters or digits long and is left-justified with blank fill 
within this field. A terminal name used is obtained from the network 
configuration file entry for the device. 

For an application-to-application connection, this field contains blanks. 

tclass-i This 6-bit field contains the integer terminal class associated by the network 

with the device on connection i. The integer used in the field is one of 
those described for the tc field of the connection-request supervisory message 
presented in section 3. The integer is changed during a QTGET call whenever 
the terminal user has entered a TIP command to change the terminal class of 
the device on connection i. 

This field is not used for application-to-application connections. 
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page-width-i This 12-bit field contains the integer page width value associated by the net¬ 

work with the device on connection i. The integer used in the field has the 
significance explained in sections 2 and 3. The integer is changed during a 
QTGET call whenever the terminal user has entered a TIP command to change the 
page width or terminal class of the device on connection i. 

This field is not used for application-to-application connections. 

family-name-i This 42-bit character data field contains the display code characters of the 

permanent file family name associated by the network with device connection i. 

The family name is one to seven letters or digits long and is left-justified with 
blank fill within this field. 

This field is not used for application-to-application connections. 

dev-type-i This 6-bit field contains an integer value to identify the type of connection for 

connection i. The integer used in this field is one of those described for the 
dt field of the connection-request supervisory messages presented in section 3. 
Typical values are: 

0 This connection is a device-to-application connection for a console. 

5 This connection is an application-to-application connection within the 
same host. 

6 This connection is an application-to-application connection between • 
hosts. 

12 This connection is a device-to-application connection for a device 

thru with a site-defined device type. 

15 

page-length-i This 12-bit field contains the integer page length value associated by the 

network with the device on connection i. The integer used in the field has 
the significance explained in sections 2 and 3. The integer is changed during 
a QTGET call after the terminal user enters a TIP command to change the page 
length or terminal class of the device on connection i. 

This field is not used for application-to-application connections. 

usei name-i This 42-bit character data field contains the display code characters of the 

NOS user name associated by the network with device connection i. The user 
name is one to seven letters, digits, or asterisks long and is left-justified 
with blank fill within the field. 

This field is not used for application-to-application connections. 

sec-lvl-i This 6-bit field contains a binary Integer identifying the security access level 

of the communication line in use. Access to information or resources requiring a 
security level higher than this value should be prohibited. This value is the AL 
parameter from the NDL statement defining the communication line used by the 
terminal. This field can have the values 0 through 15. 

max-block-size-i This 12-bit field contains the integer downline block size in character units for 

the device on connection ii This block size is based on the network 
configuration file information for the device or the local configuration file 
information for an application-to-application connection. The block size is a 
suggested value for adjusting the current-trans-size field based on efficiency 
considerations for the site. 

sbl-i This 6-bit integer field contains the number of blocks permitted by the network 

to be in transit to connection i at a given moment. This block limit is based on 
the network configuration file information for the connection. The value used in 
this field determines the number of QTPUT calls that can be made on connection i 
before a QTGET call returns an indication that a block was delivered to the 
connection. A typical value is 2 for a device-to-application connection and 7 
for an application-to-application connection. 


Figure 8-1. Network Information Table Format (Sheet 22 of 24) 


60499500 V 


8-23 



current-abn-i 

This 18-bit integer field contains the binary block number assigned by QTRH to 
the block sent to connection i by the last STRUT call involving that connec¬ 
tion, Every block sent by 9TRM is assigned a number; the number assigned is 
sequential within the blocks sent to a given connection, and the sequence is 
restarted each time a new connection is assigned to the connection number. 

acknowledged-abn-i 

This 18-bit integer field contains the binary block number assigned by STRH to 
the block last acknowledged on connection i. QTRH updates this field during^ 
a QTGET call, when QTRH determines that a block-delivered message has been 
received. 

state-i 

This 6-bit field contains the integer flag identifying the current processing 
state of connection i. This field has the values: 


0 

This connection number is currently not in use. 


1 

This connection is currently in a transition state while a new con¬ 
nection is being established. No other information in the associated 
10-word entry for this connection should be considered accurate. 


2 

This connection is in use and in a normal state for input or output 
processing by the application program. 


4 

This connection is currently in a transition state while a new con¬ 
nection is being established. No other information in the associated 
10-word entry for this connection should be considered accurate. 

This value is used for application-to-application connections only. 


5 

This connection is currently in a transition state while the connection 
is being loaned to another application program. 


6 

This connection has been loaned to another application program. 


7 

This connection is currently in a transition state while the connection 
loaned to another application program is reestablished with this 
program. 


8 

This connection is currently in a user break state while QTRH waits for 
the break interrupt marker C8I/HARK/R) supervisory message- 


9 

This connection is currently in a flow control break state while QTRH 
waits for the reset (FC/RST/R) supervisory message. 


10 

This device connection is currently in an interrupt state while QTRH 
waits for the interrupt acknowledgment (INTR/RSP/R) supervisory 
message. 


11 

This connection is currently in a termination state while QTRH waits 
for the connection termination acknowledgment (CON/END/N) supervisory 
message. 


12 

This device connection is currently in a user break state while QTRH 
waits for a downline data block acknowledgment (FC/ACK/R) supervisory 
message so that it can send the resume output mark (RO/HARK/R) 
synchronous supervisory message. 


13 

This device connection is currently in a user break state while QTRH 
waits for either a downline data block acknowledgment (FC/ACK/R) 
supervisory message so that it can send the resume output mark 
(RO/HARK/R) synchronous supervisory message, or the break indicator 
mark (BI/MARK/R) synchronous supervisory message. 


14 

This device connection is currently in a user interrupt state while 

QTRH waits for a downline data block acknowledgment (FC/ACK/R) 
supervisory message so that it can send the terminate output mark 
(TO/HARK/R) synchronous supervisory message. 
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current-abl-i 


This 6-bit field contains a binary integer identifying whether the connection is 
a Loaned connection from another application program. It can have the following 
values: 

0 This is not a Loaned connection. 

1 This is a loaned connection. 

This 6-bit integer field contains the number of sequential QTPUT calls that 
currently can be made for connection i without waiting for acknowledgment of 
delivery to the device of application. QTRH updates this field during QTGET 
and QTPUT calls, and the application program should examine the field before 
making a QTPUT call involving the connection. The values used in this field 
range from 0 to the value contained in the abl-i field; a value of 0 indicates 
that no blocks currently can be sent (the maximum number of blocks are in 
transit to the connection). 

This 6-bit integer field contains a binary integer identifying the current 
character code set for receiving synchronous supervisory messages. When all 
connections are initially established, the character set for synchronous 
supervisory messages will always be 2, However, the application program can 
change that by calling QTSUP. The field can have any of the following values: 

2 8-bit ASCII codes are packed 7.5 bytes per 60-bit word and received in 
normalized mode. 

3 8-bit ASCII codes are packed 5 bytes per 60-bit word (each character 
code is right-justified within a 12-bit byte and zero filled to the 
Left) and received in normalized mode. 

This 6-bit integer field contains a binary integer identifying the current 
character code set and byte packing convention along with the mode of data used 
by the program for input on this connection. It can have any of the following 
values: 

1 A 60-bit character is in a 60-bit word. 


upline-abh-i 


downline-abh-i 


2 8-bit ASCII codes are packed 7.5 bytes per 60—bit word and received in 
normalized mode. 

3 8-bit ASCII codes are packed 5 bytes per 60-bit word (each character 
code is right-justified within a 12-bit byte and zero filled to the 
Left) and received in normalized mode. 

4 6-bit display codes are packed with 10 bytes per 60-bit word. 

10 8-bit ASCII codes are packed 7.5 bytes per 60-bit word and received in 
either transparent or normalized mode. 

11 8-bit ASCII codes are packed 5 bytes per 60-bit word,(each character 
code is right-justified within a 12-bit byte and zero filled to the 
left) and received in either transparent or normalized mode. 

The initial value stored here, when the connection is established, is taken from 
the chai set field at the time QTOPEN was called. The value can be changed by 
calling QTSUP with the smc parameter set to 2 after storing the desired value in 
the char-set field. 

This 60-bit field contains the binary application block header received by 
QTRH with the last input data block delivered by a QTGET call for connection i. 
This field has the format and contains the information described in section 2. 

This 60-bit field contains the binary application block header created by QTRH 
to send with the Last output data block involved in a QTPUT call for connec¬ 
tion i. This field has the format and contains the information described in 
section 2. 



60499500 V 


8-25 



In figure 8—1, the number of 10—word entries is 
shown as n and is communicated to QTRM as the value 
in the num-conns field. The connection number for 
a specific terminal or application is identified as 
i in the field descriptions. 

For the convenience of programmers using COBOL 5.2 
or subsequent versions that permit manipulation of 
information in 6—bit bytes, the fields within the 
network information table are defined in 6-blt byte 
multiples. The first occurrence of each field 
within figure 8—1 Indicates the type and size of 
the COBOL data item needed to define the field 
properly. These indications-have the form I(x) or 
C(y), where I indicates binary integer data, C 
indicates character data, x indicates the number of 
bits comprising the integer, and y indicates the 
number of 6-bit display-code characters comprising 
the character string. 

SUBROUTINES 

Calls to the subroutines comprising QTRM do not 
contain many, parameters because most communication 
between an application program and QTRM occurs 
through the fields in the network Information table. 
The format of the subroutine calls conforms to the 
general guidelines given for the compiler-language 
form of the AIP routines, as described in sections 
4 and 5. The QTHtM routines reside in the libraries 
NETIO and NETIOD. These libraries are accessed as 
described in sections 4 and 6. 

The format of the subroutine calls is given in the 
following subsections. Because QTRM is designed to 
be COBOL-oriented, the subroutine descriptions are 
COBOL-oriented. As described in section 4, QTRM 
can be used by programs written in languages other 
than COBOL. 

Initiating network access (qtopen) 

The application program begins communication with 
the network by calling QTOPEN. This call has the 
format shown in figure 8-2. 


ENTER FORTRAN-X QTOPEN USING net-info-table 


net-info-tabie An input parameter, specifying 
the symbolic address for word 1 
in the global portion of the 
network information table that 
should be used by QTRM during 
access to the network. In a 
COBOL call, this parameter is 
the Data Division descriptor 
for a level 01 data item con¬ 
taining level 02 or lower level 
data items in the form de¬ 
scribed in figure 8-1. The 
fields in the network informa¬ 
tion table must be initialized 
before the call to QTOPEN is 
issued. 


Figure 8-2. QTOPEN Statement COBOL Call Format 


QTOPEN Is normally called only once per network 
■communication access but can be called again after 
a QTCLOSE call or if the QTOPEN call did not 
successfully complete the first time. No QTRM call 
other than QTCLOSE can be made before QTOPEN is 
called. The call to QTOPEN performs the following 
functions: 

Identifies to QTRM the address of the network 
Information table defined by the application 
program 

Allows QTRM to use the information already 
placed in the network information table by the 
application program 

Allows QTRM to Initialize the connection entry 
portions of the network information table and 
to store its own Information in the global 
portion of the table 

Causes QTRM to identify the application program 
to the network 

Before QTOPEN is called, the application program 
must place information in the following fields of 
the table: 

Application-name 

Char-set 

Num-conns 

A-to-A 


During processing of the call, QTRM uses this 
Information to make appropriate AIP calls. For 
example, suppose the application program makes the 
following call: 

ENTER FORTRAN-X QTOPEN USING NIT 

where NIT is the network information table symbolic 
address and contains the application-name RMV2, the 
num-conns value of 5, and the char—set value of 4, 
In the Data Division of the program code, NIT 
appears as: 

WORKING-STORAGE SECTION. 

01 NIT. 

02 GLOBAL. 

03 APPLICATION-NAME PIC X(7) VALUE IS 
"RMV2". 

03 CHAR-SET PIC 9 COMP-4 VALUE IS 4. 

03 NUM-CONNS PIC 99 COMP-4 VALUE IS 5. 

03 FILLER X(30). 


QTRM then connects the program to the network. QTRM 
identifies the program as the network application 
program called RMV2. RMV2 supports five devices 
simultaneously on connections numbered 1 through 5, 
uses 6-bit display code for all input and output 
transmissions, and cannot process transparent mode 
transmissions. 
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If QTOPEN cannot successfully complete, the appli¬ 
cation program will abort unless you select the 
option to have control return to the application 
program when the QTOPEN call fails. This option is 
chosen by the application program calling QTCMD 
with cc=9 before calling QTOPEN. The application 
program then checks the return-code field of the 
network information table to determine if the 
QTOPEN call successfully completes or not. 

If the QTOPEN call is not successful, the sec— 
return-code field of the network information table 
contains the reason code indicating why the QTOPEN 
request failed. The QTOPEN call can be re—Issued 
as many times as necessary until QTOPEN success¬ 
fully completes. 

When the QTOPEN call is successfully completed, the 
application program either performs processing not 
related to network communication, uses the QTCMD 
call to alter the way QTRM executes, or uses the 
QTGET call and the sleep field of the network 
Information table to suspend its processing until a 
device or application requests access to it. As 
soon as a device connection is completed (as soon 
as the state field in a connection entry of the 
network information table changes to 2), the 
program must identify itself to the device by 
sending a message to it using a call to QTPUT. 


COMMAND TO QTRM (QTCMD) 

The application program either wants to alter the 
way QTRM is executing or wants QTRM to perform some 
other Internal activity for the application program. 
This call has the format shown in figure 8-3. 


If QTCMD is called before calling QTOPEN and the 
command code is not 9, QTRM aborts the applica¬ 
tion, After QTOPEN is called, an invalid call to 
QTCMD does not abort the application. Instead, 
QTCMD rejects the call and stores a nonzero value 
in the return—code field of the network information 
table indicating that the call was rejected. A 
value of zero in the return—code field after the 
QTCMD call indicates that the call was accepted and 
QTRM processing has been changed. If a QTCMD call 
is made with cc=9, the network information table 
might not exist yet (QTOPEN has not been called) , 
so QTCMD does not return any response to the 
return-code field of the network information 
table. If the QTCMD call is rejected, the sec- 
return-code field of the network information table 
contains the reason code indicating why the call 
was not successful. 


Notification of Break Indicator Mark (cc=1) 

QTRM normally does not notify the application 
program when it receives the break indicator mark 
(BI/MARK/R synchronous) supervisory message. 

If this command code is specified, QTRM processing 
changes to inform the application program when it. 
receives the break indicator mark, line application 
program is then required to send the response (the 
RO/MARK/R synchronous supervisory message). This 
can be done by calling NSTORE to set up the super¬ 
visory message and then calling QTTIP to send the 
supervisory message to NAM. 

The second parameter (wsa) is not required for this 
call and can be omitted. 


ENTER FORTRAN-X RTCHO USING cc, wsa 


cc An input parameter, specifying the command 
code for the activity or change in proc¬ 
essing that the application program wants 
QTRM to make. In a COBOL call, this 
parameter is the Data Division descriptor 
for a Level 01 data item. 

wsa An input parameter, specifying the buffer 
to be used in conjunction with processing 
the command code. In a COBOL call, this 
parameter is the Data Division descriptor 
for a level 01 data item. Not all command 
codes require this parameter. For those 
that do not, the parameter can be omitted. 


Figure 8-3. QTCHD Statement COBOL Call Format 


Notification of User/Application 
Interrupts (cc=2) 

QTRM normally ignores a user or application 
interrupt. 

If this command code is specified, QTRM processing 
changes to Inform the application program when it 
receives a user/application Interrupt. QTRM also 
sends a response for the user/application inter¬ 
rupt. For terminal connections, the character 
entered by the terminal user will be stored in 
ASCII in the sub-return-code field of the network 
information table. For application-to-application 
connections, the parm parameter from the appli¬ 
cation interrupt will be stored in the sub-return- 
code field. 

The second parameter (wsa) is not required for this 
call and can be omitted. 


The command code (cc) determines when the appli¬ 
cation program can call QTCMD. If the command code 
is 9, the application program should call QTCMD 
before calling QTOPEN, If the command code is not 
equal to 9, the call to QTCMD must be done after 
QTOPEN is called. Before making a call to QTCMD, 
the application program might have to update some 
fields in the network information table depending 
on which command code is specified. The command 
codes that have been defined are described in the 
following paragraphs. 


Notification of Inactive Connections (cc=3) 

QTRM normally ignores notification of inactive 
connections. 

If this command code is specified, QTRM processing 
changes to inform the application program whenever 
it is notified of an inactive connection. 

The second parameter (wsa) is not required for this 
call and can be omitted. 
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Support of NAM K-dispiay (cc=4) 

QTRM normally ignores all K-display supervisory 
messages. 

If this command code is specified, QTRM processing 
changes to inform the application program whenever 
it receives a K—display supervisory message. 

The second parameter (wsa) is not required for this 
call and can be omitted. 

Notification of Initial G>nnection 
Requests (cc=5) 

QTRM normally does not inform the application 
program about a new connection or the reconnection 
of a loaned connection until the connection is 
fully established and ready for input/output data. 

If this command code is specified, QTRM processing 
changes to Inform the application program whenever 
it receives a connection request (CON/REQ/R) super¬ 
visory message. The 10-word entry in the network 
information table is updated by QTRM for the new 
connection, but no data traffic is allowed. Data 
traffic is not allowed until the connection is 
initialized, which is when a QTGET call results in 
return code values 2, 14, or 18 for this connection. 

If the application program wants to examine data 
that might have been passed to it from the previous 
application program that held the connection, this 
QTCMD call is required. 

The second parameter (wsa) is not required for this 
call and can be omitted. 


Store Address in Parm-addr Field (cc=6) 

For calls to QTLINK, QTENDT, and QTLEND the appli¬ 
cation program might want to or be required to 
store an address in the parm-addr field of the 
network information table. This might not be 
possible if the application program is written in 
an implementation language, such as COBOL, which 
does not have this capability. In this case, QTCMD 
can be called to store the address in the parm-addr 
field of the network Information table before 
calling the QTLINK, QTENDT, or QTLEND routine. 

The second parameter (wsa) is required for this 
command code. QTCMD stores the address of wsa in 
the parm-addr field of the network information 
table. 


Automatic Processing of User Breaks (cc=7) 

QTRM normally informs the application program when 
it receives a user break. All data received after 
the user break and before the break indicator mark 
is delivered to the application program. The appli¬ 
cation program is not informed when QTRM receives 
the break Indicator mark. 

If this command code is specified, QTRM processing 
changes to no longer inform the application program 
about the user break or break Indicator mark. QTRM 
sends the appropriate responses and all data 
received after the user break and before the break 
indicator mark is discarded. 


The second parameter (wsa) is not required for this 
call and can be omitted. 


Selective Polling of-Connections for Data (cc=8) 

QTRM normally polls all connections for data when 
QTGET is called. Therefore, the application pro¬ 
gram can receive data from any of its connections 
that have list processing turned on (list proc¬ 
essing is turned on by default and can be turned 
off by calling QTSUP with smc=7). 

If this command code is specified, QTRM process¬ 
ing can be changed so that list processing is no 
longer used. In this case, the application program 
must specify a connection number (stored in the 
connection-number field of the network information 
table) before each QTGET call. QTRM polls for data 
only from that connection. Asynchronous supervisory 
messages are not processed unless the connection 
number is zero. If the connection number is zero, 
QTRM processes only asynchronous supervisory mes¬ 
sages. To change QTRM back to list processing, 
call QTCMD with cc=8 and the appropriate value 
stored in the word pointed to by the wsa parameter. 

The second parameter (wsa) is required for this 
command code. It should be the symbolic address of 
a word containing the processing option the appli¬ 
cation program desires. The wsa parameter can have 
the following values: 

0 QTGET first retrieves and processes asyn¬ 
chronous supervisory messages. If none are 
processed that require return of control to 
the application program, QTGET uses list 
processing to retrieve a message queued for 
the application program on any of its 
connections. This is the normal mode of 
operation by QTGET, 

1 QTGET retrieves only messages for the 
connection number the application program 
stores in the connection-number field of 
the network information table before QTGET 
is called. If the connection number is 
zero, QTGET only processes asynchronous 
supervisory messages. If the connection 
number is not valid, the QTGET call is 
rejected and no data is retrieved. 


Application Processing of NETON Rejects (cc=9) 

QTRM normally aborts the application program if the 
QTOPEN call cannot be successfully completed. This 
occurs if the NETON request Issued by QTOPEN fails. 
If this command code is specified, QTRM does not 
abort the application program. Instead, QTOPEN 
stores the value 41 in the network information 
table indicating that the QTOPEN call aid not 
successfully complete. 


After the QTOPEN call, the application program must 
check the return-code field to deteirmine if the 
call was successful or not. If the QTOPEN call was 
not successful, QTOPEN stores a reason code indi¬ 
cating why the QTOPEN request failed in the sec- 
return—code field of the network information table. 
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Application Processing of ERR/LGL 
Supervisory Messages (cc=10) 

QTRM normally aborts the application program if it 
receives an ERR/LGL supervisory message. If this 
command code is specified, QTRM does not abort the 
application program. 


SENDING DATA (QTPUT) 

The application program sends data through the net¬ 
work by calling QTPUT. This call has the format 
shown in figure 8-4. 


ENTER FORTRAN-X QTPUT USING ta-out-acn^ 

ta-out-acn^ An input parameter, specifying the 
symbolic address of the output 
text area for the device or appli¬ 
cation using connection acn^. In 
a COBOL call, this parameter is 
the Data Division descriptor for 
a level 01 data item with a length 
defined by the max-trans-size 
value in the network information 
table. Data contained in ta-out- 
acn^- is subject to the same con¬ 
straints as normalized mode data 
in the text area used by any 
NETPUT call to AIP. These 
constraints are described in 
section 2. 


Figure 8-4. QTPUT Statement COBOL Call Format 

Before making a call to QTPUT, the application 

program must perform the following operations: 

Check the connection entry in the network 
information table to which the QTPUT call 
applies. The current-abl and/or state field 
must contain values that permit the call to’ be 
made. 

Ensure that the connection number identifying 
the connection to which the call applies is in 
the connection-number field of the network 
information table. 

Place a 1 in the int-msg field of the network 
information table if' that action is necessary. 
This field must be used to service a device in 
terminal class 4 correctly when output queuing 
is performed. Devices in that class, such as 
the 2741, have lockable keyboards. When output 
begins, the network software locks the device 
keyboard. The keyboard remains locked until a 
block is delivered that has an int—msg value of 
0 associated with it. Then the keyboard is 
unlocked and no more output to the device is 
permitted until input is completed. If a mes¬ 
sage comprising nine blocks is being sent to 
the device, the first eight must have the int- 
msg field set to 1 to prevent the network soft¬ 
ware from interpreting an intermediate portion 
of a message (a single block) as the entire 
message and prohibiting output of the remainder 
of the blocks. The last block of a message 
must always have the int-msg field set to 0 
before it is sent. 


Place a nonzero value in the q-data field of 
the network information table if the data is to 
be sent as qualified data. Qualified data can 
be used only by application-to-application con¬ 
nections. Such data has no special significance 
to the CDC network software. Qualified data is 
intended for application programs to communi¬ 
cate control information among ’ themselves 
outside of (but synchronous with) the data 
stream. Qualified data cannot be sent after a 
partial message (int-msg field set to 1 for a 
non-qualifled block) has been sent or before 
the terminating block of the message (int-msg 
field set to 0 for a nonqualified block). 

Place the data to be transmitted by the call 
into the text area Identified by the parameter 
to be used in the call. 

For devlce-to-applicatlon connections, place a 
unit separator code as a line terminator at the 
end of the data in the text area, if char-set 
is not 6-bit display code. QTRM will supply 
the final zero-byte terminator for 6-bit display 
code data for devlce-to-appllcation connections 
(this QTRM function is described in more detail 
under the heading QTRM Formatting of Display- 
Coded Output). 

Place the size of the current transmission in 
the current-trans^size field of the network 
Information table. All embedded line termi¬ 
nators of either type must be Included in the 
character count comprising the current trans¬ 
mission size. If a char-set field value other 
than 4 is used, any final unit separator must 
also be Included in the character count; if a 
char-set field value of 4 is used, the character 
count should not include the zero-byte line 
terminator that QTRM supplies automatically for 
device-to-appllcatlon connections. 

Place the correct value in the max-trans-size 
field of the network information table, if that 
information was not stored there before a pre¬ 
vious QTRM call. The max-trans-size value can 
be changed before any QTPUT call, because the 
output text area used for the call can be 
changed. QTRM uses the value in this field to 
determine the starting point of any backward 
scanning it is required to perform. 

When the QTPUT call is completed, the data block 
involved in the call usually is in transit through 
the network but is not necessarily already delivered 
to the connection. Delivery of the block, and the 
possibility of additional QTPUT calls for the same 
connection, can be tracked through QTGET calls and 
Che fields of the connection entry in the network 
information table. 


QTRM' sometimes cannot transmit a block through the 
network when a QTPUT call is made. After return 
from the QTPUT call, the application program should 
check the return-code field of the network infor¬ 
mation table to determine whether the block was 
actually transmitted. 

As an example of QTPUT use, suppose an application 
program wants to send the message WELCOME ABOARD to 
the device on connection 1. The program sends the 
prompting message with a call such as that shown in 
the following statement set: 
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MOVE " WELCOME ABOARD " TO OUT-TEXT. 

MOVE 1 TO CONNECTION-NUMBER. 

MOVE 15 TO CURRENT-TRANS-SIZE. 

ENTER FORTRAN-X QTPUT USING OUT-TEXT. 

IF RETURN-CODE NOT = 0 GO TO PROBLEM. 

Elsewhere in the program, the Data Division con¬ 
tains: 

01 OUT-TEXT PIC X(IOO). 

The Procedure Division also contains statements to 
test the entry for connection 1 to see whether the 
call can be made. These tests are necessary even 
for the first transmission from the program because 
QTRM might indicate that the connection is in a 
state temporarily preventing any transmission. 

Use of the current-trans-slze field and the first 
character of the text area during display-coded 
transmissions is described later in this section. 
The tests of the table needed before the QTPUT call 
are associated with the QTGET call and are described 
in the subsection on Output Queuing Using QTRM. 


OBTAINING DATA OR CONNECTION 
STATUS (QTGET) 

The application program obtains input from a con¬ 
nection or status information about a connection by 
calling QTGET. This call has the format shown in 
figure 8-5. 


ENTER FORTRAN-X QTGET USING ta-in 


ta-in An input parameter, specifying the 

symbolic address of the input text area. 
In a COBOL call, this parameter is the 
Data Division descriptor for a Level 01 
data item with a Length defined by the 
max-trans-size value in the network 
information table. Data contained in 
ta-in is subject to the same constraints 
as normalized mode data in the text area 
used by any NETGET, NETGETF, NETGETL, or 
NETGTFL call to AIP. These constraints 
are described in section 2. 


Figure 8-5. QTGET Statement COBOL Call Format 


Before making a call to QTGET, the application 
program must perform the following operations: 

Place the correct value in the sleep field (in 
word 5) of the network information table, if 
that information was not stored there before a 
previous QTRM call. The sleep field value used 
can be changed before any QTGET call, if neces¬ 
sary. 

Place the correct value in the max-trans-slze 
field of the network information table, if that 
Information was not stored there before a prev¬ 
ious QTRM call. The max-trans-slze value can 
be changed before any QTGET call, because the 
input text area used for the call can be 
changed. 


If selective polling of connections for data is 
in effect, the connection number identifying 
the connection requesting data must be stored 
in the connection-number field of the network 
information table. If the connection number 
stored in the connection-number field is 
invalid, QTGET rejects the call and the appro¬ 
priate return code is returned. The sec- 
return-code field contains the reason code for 
the bad connection number specified. 

The application program can call QTGET to perform 
one of three functions: 

Obtain input from a specific connection 

Solicit for status information about a 
connection 

Solicit status information or input from any 
connection 

The third function, a combination of the first two 
functions, is the normal mode of operation for 
QTGET. 

QTGET first updates the status of one or more of 
its connections until a status change occurs 
requiring QTGET to return the status to the appli¬ 
cation program. When this status change occurs, 
QTGET immediately returns control to the applica¬ 
tion program. 

If this type of status change does not occur and 
QTGET has no more status changes to process, QTGET 
tries to solicit input from one of its connec¬ 
tions. Since the status change or input data can 
come from any of the application program's connec¬ 
tions, the application program cannot determine 
beforehand which connection QTGET returns a status 
change or retrieves input from. 

To perform the first two functions, the application 
program should call QTCMD to turn on selective 
polling of connections for data. The application 
program then stores the connection number of the 
connection it wants to obtain data from in the 
connection-number field of the network Information 
table. QTGET attempts to retrieve data only from 

that connection. 

If zero is stored in the connection-number field, 
QTGET updates only the status of one or more con¬ 
nections until a status change occurs that requires 
it to return information to the application program 
or the sleep and/or xsleep timers expire. No 

attempt is made to solicit input data from any of 
the connections. This function allows an appli¬ 
cation program to solicit status changes only and 
not retrieve any input data. 

If a nonzero connection number is stored in the 
connection-number field, that connection number 
must be a valid connection from which QTGET can 
retrieve data. If invalid, QTGET rejects the call 
and no attempt is made to solicit input. If valid, 

QTGET attempts only to solicit input data from that 

connection. No attempt is made to solicit status 
changes for any connections including the one that 
input data is being solicited from and no attempt 
is made to solicit input from any other connection 
even if none is available from the designated 
connection. This function allows an application 
program to control the source of its input data. 
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Before calling QTGET, the application program 
should first determine under what conditions it 
would like to receive control back from QTGET. 
This is established by storing the appropriate 
values in the sleep and xsleep fields of the net¬ 
work information table. The application program 
can choose to receive control back only after QTGET 
obtains data or a connection status change or after 
a specified time period (which can be immediately) 
if no new status or data has been received. 

If QTRM receives an input block, the return-code 
field is set to zero. Control returns to the 
program after the connection-number field has been 
set to Identify the connection affected by the 
call, and a single input block from that connection 
is delivered. 

After return from a QTGET call, the application 
program should perform the following operations: 

Check the return—code field of the network 
information table to determine whether informa¬ 
tion or status was returned by the call 

Check the connection-number field of the network 
information table to determine which connec¬ 
tion, if any, is involved with the information 
or status returned in the call 

Take an action appropriate for the return-code 
field value resulting from the call 

Depending on the sleep value used when making the 
call and on events in the network, the response 
from any QTGET call can be any of the following: 

Nothing (no data block, no status, and no con¬ 
nection entry changes). 

No input data block but one or more connection 
entries are updated to reflect delivery of 
previously sent blocks to the corresponding 
connections; the current-abl and acknowledged- 
abn fields are updated to reflect such deliver¬ 
ies. 

An input data block and connection entry fields 
are updated. 

An input data block but no connection entry 
fields are changed. 

Status information (Indication of a new connec¬ 
tion, a reconnect of a loaned application, an 
abort of a loaned connection, a user interrupt, 
an application Interrupt, a user-break, or 
other status change on an existing connection) 
and connection entry fields are updated. 

Status information (shutdown in progress, block 
discarded, operator command, operator K—display 
command. Inactive connection, and so forth) but 
no connection entry fields are changed. 


The action taken by the application program after a 
QTGET call must not assume that only one of these 
conditions is possible and should not exclude any 
of them. Use of the sleep field value and the 
updating of Information in the connection entries 
Is described further under Output Queuing Using 
QTRM later in this section. 


The following example of QTGET use permits an 
application program to suspend its operation when 
there is no input for it to process, to process any 
input that does exist, and to perform any processing 
related to changes in the status of the network or 
of a specific device: 

MOVE -1 TO SLEEP. 

ENTER FORTRAN-X QTGET USING IN-DATA. 

IF RETURN-CODE NOT =0, GO TO STATUS- 
CHECK. 

PERFORM PROCESS-INPUT. 

On return from the QTGET call, the application 
program either has data to process because the 
return-code field is 0 or else has status changes 
to process because the return-code field is not 0. 
If the return-code field contains a 0, the data 
block returned as a result of the QTGET call is 
found in the text area called IN-DATA. 

The actions required by an application program for 
a specific nonzero return-code field value are 
described in the field definition Information given 
previously in this section. The interaction of the 
QTGET calls and the fields in the network infor¬ 
mation table are the primary processing control 
mechanism of any application program using QTRM. 
If the QTGET call returns data and the character 
set is display code, QTBtM blank fills the last line 
of the message if necessary to make the message end 
on a word boundary. 

SENDING A SYNCHRONOUS 
SUPERVISORY MESSAGE (QTTIP) 

The application program can send a synchronous 
supervisory message through the network by calling 
QTTIP. The call format for QTTIP is identical to 
QTPUT. The message can be in char-set 2 or 3 for¬ 
mat . 

If the application program sends a synchronous 
supervisory message -that has a response (CTRL/CHAR/ 
N or CTRL/RTC/R), the response is delivered when the 
application program calls QTGET. The application 
block type field of the upllne-abh-i field ident¬ 
ifies the data as a supervisory block. Supervisory 
message responses are always returned to the appli¬ 
cation program as char-set 2 by default. 

QTSUP can be called to change the input character 
type to 3. 

QTRM sometimes cannot transmit a synchronous super¬ 
visory message through the network when a QTTIP 
call is made. After return from the QTTIP call, 
the application program should check the return- 
code field of the network information table to 
determine whether the synchronous supervisory 
message was actually sent. If the return-code 
field is nonzero, the sec-return-code field will 
contain the reason code indicating why the super¬ 
visory message was not sent, 

UNKING AN APPLICATION TO ANOTHER 
APPLICATION (QTLINK) 

The application program requests a connection to 
another application program for the purpose of per¬ 
forming message transfers between them. This call 
has the format shown in figure 8-6. 
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ENTER FORTRAN-X 9TL1NK 


Figure 8-6. STLINK Statement COBOL Call Format 

Before making a call to QTLINK, the application 
program must perform the following operations: 

Set the A-to-A field in the network information 
table to 1. This field must be set before the 
program Issues the call to QTOPEN. 

Place the name of the application program to 
which connection is requested in the requested- 
application-name field in the network informa¬ 
tion table. 

If the application program to which connection is 
requested resides in a different host, either the 
destination host field or the lid field in the 

CON/ACRQ/R supervisory message must be filled. If 
the application program resides in the same host, 
these two fields can be zero. If the lid field is 
to be filled, it should have been previously speci¬ 
fied in the LIDCMld file. (See the NOS Installation 
Handbook). If a lid is given and a destination 

host is not, a physical identifier (PID) associated 
with that lid is used. This PID should match the 
value of a PID parameter in an NDL OUTCALL state¬ 
ment for the requested application program. If 
both the lid and the destination host are given, 
the destination host is assumed to be a PID, and 

must be previously specified as a PID for the LID 

in the LIDCMid file. If only a destination host is 
given, that name must match the value of a NAME2 
parameter in an NDL OUTCALL statement for the 
requested application program. 

The application program can specify OUTCALL 
parameters. The application program sets up the 
OUTCALL parameters in a buffer according to the 
format described in section 3 for the CON/ACRQ/R 
supervisory message, beginning with the third word 
of the message. (The first two words of the super¬ 
visory message are created by QTRM in its own 
internal buffer). The address of the buffer con¬ 
taining the OUTCALL parameters is stored in the 
parm-addr field of the network information table 
before QTLINK is called. If no OUTCALL parameters 
are specified, the parm-addr field should be zero. 
The size of the OUTCALL parameter buffer (including 
the first two words reserved for QTLINK) should be 
stored in the current-trans-slze field in the 
network information table. The size is specified 
in central memory words. If the application pro¬ 
gram cannot store an address in the parm-addr 
field, QTCMD can be called with a cc value of 6 to 
store the address. 

On return from the QTLINK request, the application 
program should check the value in the return-code 
field of the network Information table. The 
return-code from figure 8-1 is interpreted as 
follows: 

A return-code value of 0 indicates that the 
request is being forwarded to NAM. The con¬ 
nection has not yet been completed. 

A return-code value of 12 indicates that the 
request has been rejected by QTLINK. The 
sec-return-code field in the network informa¬ 


tion table contains the reason QTLINK rejected 
the call. No application connection request 
was initiated. 

The connection-number field is not changed upon 
return from the QTLINK call. A QTGET call made 
after the QTLINK call updates this field. 

After a call to QTLINK, a call to QTGET returns a 
value of 13 or 14 in the return-code field of the 
network information table. This completes the out¬ 
standing request for an appllcation-to-application 
connection. The return-code field from figure 8-1 
is interpreted as follows: 

A return—code value of 14 indicates that the 
connection to the requested application has 
been made. The connection-number field of the 
network information table contains the connec¬ 
tion number for the applicatlon-to-applicatlon 
connection. 

A return-code value of 13 indicates that the 
request for connection has been rejected. The 
sub-return-code field of the network information 
table contains the reason code returned in the 
CON/ACRQ/A supervisory message. The sec-return- 
code field of the network information table 
contains the rc2 field of the CON/ACRQ/A super¬ 
visory message and the return code plus 32 if 
the rejection was indicated by receiving a 
CON/CB/R supervisory message. 


ENDING A SINGLE CONNECTION (QTENDT) 

The application program ends communication with a 
single device or application by calling QTENDT. 
This call has the format shown in figure 8-7. 


ENTER FORTRAN-X QTENDT 


Figure 8-7. QTENDT Statement COBOL Call Format 

Before making a call to QTENDT, the application 
program should perform the following operations: 

Place the connection number for the device or 
application program to be disconnected in the 
connection—number field of the network infor¬ 
mation table. 

Send a disconnection indicator message to the 
terminal or application so that the operator or 
application program does not attempt input. 

Set the next-application-name field to zero or 
place an appropriate name or NVF command in it 
if the connection is to a device. 

If the connection being terminated is a loaned 
connection or if a next application name was 
specified, the application program can pass 
data to the original or next application. The 
address of the buffer containing the data 
should be stored in the parm-addr field of the 
network information table. The size of the 
data should be stored in the current-trans-size 
of the network Information table. The size 
should be specified as the number of central 
memory words. 
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Check the connection entry in the network 
information table to determine whether the 
current-abl field contains the same value as 
the abl field. Unless the values in these two 
fields are the same, at least one block of data 
remains undelivered to the connection and QTENDT 
should not be called to end communication with 
the connection. 

On return from the QTENDT request, the appli¬ 
cation program should check the value in the 
return-code field of the network information 
table. If the value is zero, the request was 
processed. If the value is nonzero, QTENDT 
rejected the call. The sec-return-code field 
of the network information table contains the 
reason for the rejection. The connection was 
not terminated. 

After a call to QTENDT is made, no additional 
information can be sent to the connection involved. 
Except for the state field, information contained in 
the connection entry portion of the network informa¬ 
tion table remains unchanged until the connection 
number associated with that entry is reassigned by 
the network software to another connection. 

A call to QTENDT is not necessary to end a connec¬ 
tion that has already been broken by events in the 
network. A call to QTENDT for a broken connection 
performs no action. A forced shutdown condition (a 
return-code field value of 10) is equivalent to a 
QTCLOSE call because QTRM automatically ends all 
connections without action by the application 
program. 

As an example of QTENDT use, consider the following 
situation. The application program receives a com¬ 
mand on connection number 4 that indicates the 
terminal user wants to end communication with the 
program. The program checks the fields in the con¬ 
nection entry of the network information table and 
determines that no blocks remain undelivered from 
previous QTPUT calls.' Because the terminal user has 
requested that communication be ended, the program 
does not send a block to Indicate that action. 
Instead, the following code is executed: 

MOVE 4 TO CONNECTION-NUMBER. 

ENTER FORTRAN-X QTENDT. 

Upon return from the QTENDT call, connection number 
4 becomes available for assignment by the network 
software to a new connection serviced by the pro¬ 
gram. The program therefore executes code that 
cleans up any remaining information in other tables 
or buffers concerning the old connection 4, so that 
no confusion exists if another device or application 
program is assigned to the same number. 


LOANING A SINGLE CONNECTION (QTLEND) 

The application program can temporarily switch a 
device connection to another application program by 
calling QTLEND. This call has the format shown in 
figure 8-8. 

Before making a call to QTLEND, the application 
program should perform the following operations: 

Place the connection number for the device to 
be switched in the connection-number field of 
the network information table. 


ENTER FORTRAN-X QTLEND 


Figure 8-8. QTLEND Statement COBOL 
Call Format 


Place the name of the application program the 
device is to be switched to in the next- 
application-name field. 

Check the connection entry in the network 
information table to determine whether this 
device connection is a loaned connection from 
another application program. If so, this 
connection cannot be switched to another appli¬ 
cation program. It can only be returned to the 
original application program. 

Check the connection entry in the network 
information table to determine whether the 
current-abl field contains the same value as 
the abl field. If the values in these two 
fields are not the same, at least one block of 
data remains undelivered to the connection and 
QTLEND should not be called to switch the 
connection. 

The application program can pass up to 52 words 
of information to the application program that 
is to receive the device connection. The 
address of the buffer containing the data 
should be stored in the parm-addr field of the 
network information table. If the parm-addr 
field contains zero, QTRM assumes that no data 
is to be passed. The number of words of data 
to be passed should be stored in the current- 
trans-size field of the network information 
table. If the application program cannot store 
an address in the parm-addr field, QTCMD can 
be called with a cc value of 6 to store the 
address. 

Check the state field in the connection entry 
in the network information table to verify that 
the connection is in the normal state (state 
value is 2). Connections can be loaned only if 
they are in the normal state. 

After making the call to QTLEND, the application 
program should check the contents of the return- 
code field to determine if the QTLEND call was 
accepted. If the return-code is zero, the call was 
accepted. If the return-code is nonzero, QTLEND 
rejected the connection' loan request. The sec- 
return-code field in the network information table 
indicates the reason QTLEND rejected the connection 
loan request. 

After a successful call to QTLEND is made, no 
additional information can be sent to the connec¬ 
tion Involved until the connection is returned. 
Except for the state field, information contained 
in the connection entry portion of the network 
information table remains unchanged. The con¬ 
nection entry and corresponding connection number 
remain in use and are not assigned to a new con¬ 
nection. When the device is reconnected to the 
application program, it will have the same 
connection number as before. 
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ISSUE SUPERVISORY MESSAGES (QTSUP) 

The application program can call QTSUP to send an 
asynchronous supervisory message to NAM any time 
after QTOPEN Is called. This call has the format 
shown in figure 8-9. 


ENTER FORTRAN-X QTSUP USING smc,wsa 


smc An input parameter, specifing the super¬ 
visory message code for the supervisory 
message that the program wants to send. 

In a COBOL call, this parameter is the 
Data Division descriptor for a level 01 
data item. 

wsa An input parameter, specifying the buffer 
to be used in conjunction with processing 
the supervisory message code. In a COBOL 
call, this parameter is the Data Division 
descriptor for a level 01 data item. Not 
all supervisory message codes require this 
parameter. For those that do not, this 
parameter can be omitted. 


Figure 8-9. QTSUP Statement COBOL Call Format 

Before making a call to QTSUP, the application 
program may need to update some fields in the net¬ 
work information table, depending on which super¬ 
visory message code is specified. The supervisory 
message codes that have been defined are described 
in the following paragraphs. 

After the call to QTSUP, the application program 
should check the return-code field in the network 
Information table. If this field is set to zero, 
the QTSUP request has been processed. If it is 
nonzero, QTSUP rejected the request and no super¬ 
visory message was sent to NAM. The sec-return- 
code field contains the reason code indicating why 
QTSUP rejected the call. 


Send Supervisory Message (smc==0) 

The application program has build the asynchronous 
supervisory message it wants to send to NAM. Before 
making the call to QTSUP, the application program 
should perform the following operations: 

Place the size of the supervisory message in 
the current-trans-slze field in the network 
information table. The size should be speci¬ 
fied in number of words. 

The second parameter (wsa) is required for this 
supervisory message code. It should be the 
symbolic address of a buffer containing the 
supervisory message that is to be sent. 

QTSUP will build the application block header word 
and send the supervisory message without performing 
any validity checks on the supervisory message. 

QTRM will abort the application program if the 
application attempts to send CONACR, CONEND, 
INTEAPP, and FCBRK by calling QTSUP with SMC=0. 


Doing so will cause conflicts with QTRM. Instead, 
INTRAPP and FCBRK can be sent by SMC=A and SMC=l, 
respectively. CONEND can be sent by calling QTENDT 
or QTLEND and CONACR can be sent by calling QTLINK. 


Send Flow Control Break (smc=1) 

The application program wants to send an FC/BRK/R 
supervisory message. Before making the call to 
QTSUP, the application program should perform the 
following operations: 

Check the connection entry in the network 

Information table for which the FC/BRK/R is. to 
be applied. If the connection is not in the 
normal state (state field value is not 2), the 
supervisory message cannot be sent until the 
connection has been changed to the normal state. 

Place the connection number of the connection 
to receive the break in the connection-number 

field of the network Information cable. 

Place the reason code for the break in the sub¬ 
reason-code field of the network information 
table. 

The second parameter (wsa) is not required 

for this supervisory message code and can be 
omitted. 

After this call, NAM discards all upline and 
downline messages queued on this connection until 
the FC/RST/R supervisory message is received from 
the other end. When QTGET receives this supervi¬ 

sory message, it notifies the application pro¬ 
gram which can then resume input/output on this 
connection. 


Change Input Character Set (smc=2) 

The application program wants to change the input 
character set for the connection. Before making 
the call to QTSUP, the application program should 
perform the following operations: 

Place the connection number of the connection 
to have its input character set changed in the 
connection—number field of the network infor¬ 
mation table. 

If the input character set for data messages is 
being changed, place the new character set value 
in the char-set field of the network informa¬ 
tion table. Otherwise, zero the char-set field. 

If the input character set for synchronous 
supervisory messages is being changed, place 
the character set value 2 or 3 in the parm- 
flagl field of the network information table. 
Otherwise, zero the parm-flagl field. 

The second parameter (wsa) is not required for 
this supervisory message code and can be 
omitted. 

QTSUP will create a DC/CICT/R supervisory message 
and send it to NAM. 
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Truncate Data (smc=3) 

The application program wants NAM to truncate data 
blocks which are too large for the application 
programs buffer. Before making the call to QTSUP, 
the application program should perform the follow¬ 
ing operations: 

Place the connection number of the connection 
to have Its data truncated In the connection- 
number field of the network Information table. 
If the application program wants truncation to 
be performed on all existing and future connec¬ 
tions, store zero in the connection-number 
field. 

The second parameter (wsa) is not required for 
this supervisory message code and can be 
omitted. 

QTSUP will create a DC/TRU/R supervisory message 
and send it to NAM. 


Send Application Interrupt (smc=4) 

The application program wants to send an INTR/APP/R 
supervisory message to the application program or 
device at the other end of the connection. Before 
making the call to QTSUP, the application program 
should perform the following operations: 

Check the connection entry in the network 
Information table for which the FC/BRK/R is to 
be applied. If the connection is not in the 
normal state (state field value is not 2), the 
supervisory message cannot be sent until the 
connection has been changed to the normal state. 

Place the connection number of the connection 
to receive the INTR/APP/R supervisory message 
in the connection-number field of the network 
information table. 

Place the parm value for the INTR/APP/R super¬ 
visory message in the sub-return-code field of 
the network information table. 

The second parameter (wsa) is not required 
for this supervisory message code and can be 
omitted. 


QTSUP will create the INTR/APP/R supervisory message 
and send it to NAM. If it is a device connection, 
QTSUP will also send a TO/MARK/R synchronous super¬ 
visory message after the INTR/APP/R supervisory 
message. 

Change to Full-Duplex List 
Processing (smc=5) 

The application program wants to change list 
processing on a connection to full-duplex mode. 
Before making the call to QTSUP, the application 
program should perform the following operations: 


Place the connection number of the connection 
for which full-duplex processing is desired in 
the connection-number field of the network 

information table. If the application program 
wants all existing and future connections to be 
processed in full-duplex mode, store zero in 
the connection-number field of the network 

information table. 

The second parameter (wsa) is not required 

for this supervisory message code and can be 

omitted. 

QTSUP will create a LST/FDX/R supervisory message 
and send it to NAM. 

Change to Half-Duplex List 
Processing (smc=6) 

The application program wants to change list 
processing on a connection to half-duplex mode. 
Before making the call to QTSUP, the application 
program should perform the following operations: 

Place the connection number of the connection 
for which half duplex processing is desired in 
the connection-number field of the network 
information table. If the application program 
wants all existing and future connections to be 
processed in half duplex mode, store zero in 
the connection-number field of the network 
information table. 

Place the value 1 in the parm-fiagl field of 
the network information table if the appli¬ 
cation program wants the connection to be 
initially disabled for normal list processing. 
Place the value 0 in the parm-flagl field if 
the connection is to be initially enabled for 
list processing. 

The second parameter (wsa) is not required 
for this supervisory message code and can be 
omitted. 

QTSUP will create a LST/HDX/R supervisory message 
and send it to NAM. 


Turn List Processing Off (smc=7) 

The- application program wants to turn list process¬ 
ing off for a connection. Before making the call 
to QTSUP, the application program should perform 
the following operations: 

Place the connection number of the connection 
to be turned off in the connection-number field 
of the network information table. 

The second parameter (wsa) is not required 
for this supervisory message code and can be 
omitted. 

QTSUP will create a LST/OFF/R supervisory message 
and send it to NAM. 
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Turn List Processing On (smc=8) 

The application program wants to turn list process¬ 
ing on for a connection. Before making the call to 
QTSUP, the application program should perform the 
following operations: 

Place the connection number of the connection 
to be turned on in the connection-number field 
of the network Information table. 

The second parameter (wsa) is not required 
for this supervisory message code and can be 
omitted. 

QTSUP will create a LST/ON/R supervisory message 
and send it to NAM. 


Send K-display Data (smc=9) 

The application program supports the NAM K-display 
and the host operator has assigned the K-display to 
the application program. The application program 
has generated data to send to the NAM K-dlsplay. 
The data must be in display code and can contain up 
to 32 lines. Each line can contain a maximum of 64 
characters and must be terminated by one to five 
zero bytes. Before making the call to QTSUP, the 
application program should perform the following 
operations: 

Place one of the following values in the parm- 
flagl field: 

0 K-display 'data is for the left screen 

and the application program does not 
want the operator to be able to send 

another message to the application 
program. 

1 K-dlsplay data is for the left screen 

and the application program wants to 
allow input from the operator. 

2 K-display data is for the right screen 

and the application program does not 
want the operator to be able to send 

another message to the application 
program. 

3 K-display data is for the right screen 
and the application program wants to 
allow input from the operator. 

Place the size of the K-dlsplay data in the 
current-trans-size field of the network infor¬ 
mation table. The size should be specified in 
number of central memory words. 

The second parameter (wsa) is required for this 
supervisory message code. It should be the 
symbolic address of a buffer containing the 
K-dlsplay data to be sent. 

QTSUP will create a HOP/DIS/R supervisory message 
and send it to NAM. 


Log NAM Dayfile Message (smc=10) 

The application program supports the NAM K-display 
and wants to write a message to NAM's dayfile. The 
message must be in display code and can be from one 


to eight central memory words long. The message 
must also end with at least 12 bits of zero right- 
justified in a central memory word. Before making 
the call to QTSUP, the application program should 
perform the following operations: 

Place the size of the dayfile message in the 
current-trans-size field of the network infor¬ 
mation table. The size should be specified in 
number of central memory words. 

The second parameter (wsa) is required for this 
supervisory message code. It should be the 
symbolic address of a buffer containing the 
dayfile message to be sent. 

QTSUP will create a HOP/LG/R supervisory message 
and send it to NAM. 


Alert Host Operator (smc=11) 

The application program supports the NAM K—display 
and wants to alert the host operator about a 
problem. 

The second parameter (wsa) is not required for this 
supervisory message code and can be omitted. 

QTSUP will create a HOP/ALT/R supervisory message 
and send it to NAM. 


Log Operator Entries (smc=12) 

The application program supports the NAM K-dlsplay, 
the host operator has assigned the K-display to the 
application program, and the application program 
wants to either turn on or off logging of NAM 

K-display entries in the system and NAM dayflles. 
By default all NAM K-dlsplay entries are logged in 
the dayflles. Before making the call to QTSUP, the 
application program should perform the following 
operations: 

Place one of the following values in the 

parm—flagl field: 

0 Turn off logging of NAM K-display 

entries In Che system and NAM dayflles 

1 Turn on logging of NAM K-display 

entries in the system and NAM dayflles 

The second parameter (wsa) is not required for 
this supervisory message code and can be 
omitted. 

QTSUP will create a HOP/DAY/R supervisory message 
and send it to NAM. 


Change Inactivity Timer (5mc=13) 

The application program wants to change the time 
interval for notification of inactive connections. 
The change to the time interval can be a one time 
change or a permanent change. The inactivity timer 
for the connection is restarted for the new time 
interval. Before making the call the application 
program should perform the following operations: 
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Place the connection number of the connection 
for which the inactivity timer is to be changed 
in the connection—number field of the network 
information table. If zero is stored in the 
field, then the inactivity time Interval is 
changed for all existing and future connections. 

Place one of the following values in the 

parm-flagl field: 

0 The inactivity timer is being changed 

for this one time only to the value 

stored in the word pointed to by the 
second parameter (wsa) 

1 The inactivity timer is being perma¬ 

nently changed to the value stored in 
the word pointed to by the second 

parameter (wsa) 

The second parameter (wsa) is required for this 
supervisory message code. It should be the 

symbolic address of a word containing the new 

inactivity timeout value. The time out value 

should be in units of seconds. If zero is 
specified for the timeout value and one is 

stored in the parm-flagl field, NAM no longer 
Informs the application about inactivity on the 
connection. If zero is specified for the 

timeout value and also stored in the parm-flagl 
field, no action is taken by NAM. 

If the application program did not previously call 
QTCMD (cc=3) to inform QTEM that it would like to 
be informed about inactive connections, this call 
to QTSUP is not meaningful unless it is being used 
to instruct the network software to stop reporting 
the inactive connection to QTRM. 


ENDING COMMUNICATION WITH THE 
NETWORK (QTCLOSE) 

The application program can end communication with 
all connected devices or applications and with the 
network software simultaneously by calling QTCLOSE. 
This call has the format shown in figure 8-10. 


ENTER FORTRAN-X QTCLOSE 


Figure 8-10. QTCLOSE Statement COBOL 
Call Format 

The application program should call QTCLOSE only 
once after a QTOPEN call and cannot call any other 
QTRM routines except QTOPEN after calling QTCLOSE. 
Multiple calls to QTCLOSE have no effect. The pro¬ 
gram should always call QTCLOSE as part of its 
processing termination, unless a forced shutdown 
occurs. When a forced shutdown occurs (indicated 
by a return-code field value of 10), QTRM automati¬ 
cally ends all program access to the network. 


A call to QTCLOSE performs the following operations: 


Breaks all remaining connections (devices 
receive an APPLICATION FAILED message from the 
network software) 

Ends program access to the network and makes 
new connections impossible 


QTSUP will create a DC/STMR/R supervisory message Closes the AIP debug log file and statistics 

and send it to NAM. file, if those files are being created 
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The QTCliOSE call is usually issued after one of the 
following situations arises: 

The program receives a shutdovra or idledown 
indication from the network software (indicated 
by a return-code field value of 9). 

The program detects a specific clock time. 

The program receives a shutdown command from a 
terminal user or a connected application pro¬ 
gram. 

Before making a QTCLOSE call, the application pro¬ 
gram should perform the following operations: 

Send a shutdown advisory message to all devices 
and applications still connected to the program 

Determine that all transmitted blocks have been 
delivered to the connection 

Issue QTENDT calls for all remaining device 
connections so that APPLICATION FAILED messages 
do not appear at those connections 

A QTCLOSE example complying with these recommenda¬ 
tions would be too complex for the purposes of this 
section. Examples of QTCLOSE calls appear in sev¬ 
eral contexts within the program at the end of this 
section. 


OUTPUT FORMATTING AND 
EDITING 

Output transmitted through QTEM to a device always 
uses the format effector feature of the AIP inter¬ 
active virtual terminal Interface. This format 
effector feature is completely described in section 
2, and summarized in the following subsection. 

Output transmitted through QTEM to another applica¬ 
tion within the same host need not be restricted to 
formatting conventions of the AIP Interactive Vir¬ 
tual Terminal Interface. Both application programs 
must be prepared to handle data that passes between 
them. The length of the output block Is based on 
the character set used, indicated in the char-set 
field, and is the value stored in the field named 
current-trans-size. 

If display-coded output is transmitted to a device 
(a char-set field value of 4 is used), QTEM auto¬ 
matically performs editing functions on the contents 
of the text area used. These functions Include 
placement of the final line terminator (zero-byte 
terminator) at the end of the output block, and 
determination of the number of characters in the 
block. 

The current-trans-size field for blocks sent on 
applicatlon-to-appllcatlon connections should be 
set to a value equal to the number of central memory 
words in the block using the character type speci¬ 
fied in the char-set field. The contents of a block 
are not edited. If the data is in display-code 
(the char-set field is equal to 4) and the current- 
trans-size field is equal to zero, the effective 
current-trans-slze is determined by scanning the 
output text area. 


FORMAT EFFECTORS 

The network software assumes that the first char¬ 
acter of each line in a block sent to a device 
through QTEM begins with a format effector char¬ 
acter. The format effector character controls 
placement of the line on the device output mechanism 
in a manner similar to the way a carriage control 
character functions in output sent to a batch line 
printer. Format effector characters are discarded 
by the network software, so an application program 
should always format its output to prevent the first 
character of data from being interpreted erroneously 
as a format effector character. 


DISPLAY-CODE OUTPUT EDITING 

Each block sent by a QTPUT call can contain one or 
many lines of data. Each line of data must end with 
a line terminator byte appropriate to the value in 
the char-set field of the network information table. 
The terminator must follow the last character posi¬ 
tion in the line. 

When an application program uses a char-set field 
value of 4, it must allow 12 to 66 bits of text 
area buffer space for the final 12-blt zero-byte 
line terminator. For COBOL programs, this means 
the text area used for any QTPUT call must be at 
least 11 characters longer than the longest block 
of data to be sent. 

Generating the zero-byte terminator at the appro¬ 
priate location in the text area is difficult in a 
COBOL program. QTEM therefore always generates the 
last such byte required by the block during its 
processing of a QTPUT call (interim line terminators 
must still be generated by the application program 
before the call). 

If an output block contains only one line, QTEM can 
be used as follows to perform all output formatting 
required: 

The program sets the current-trans-slze field 
of the network information table to 0. 

The program blank-fills the entire output text 
area to be used and then places the block to be 
sent into the text area (the block must Include 
the format effector character). The block must 
contain at least one character other than a 
blank. 

The program calls QTPUT. QTEM then determines 
where the text area ends by examining the max- 
trans-size field of the network information 
table. QTEM scans backward through the output 
text area, skipping over blanks until it 
encounters a nonblank character. QTEM Inserts 
the zero-byte terminator after this character, 
then calculates the number of characters in the 
block and transmits it through the network. 

This option eliminates unnecessary trailing blanks 
from the last output line of any block and makes it 
unnecessary for the application program to calculate 
how many characters are being transmitted. An 
alternate method permits transmission of trailing 
blanks, as follows: 
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The program places the output block containing 
at least one character (the format effector 
character) in the output text area. 

The program places the number of characters 
comprising the block in the current-trans-size 
field of the network Information table. 

The program calls QTPUT. QTRM scans forward 
the indicated number of character positions, 
writes the final zero-byte terminator, if 
necessary, after the last character counted, 
and transmits the block. QTRM adjusts the 
character count indicating the block length to 
compensate for the line terminator bytes it has 
added. 


Both options require that the last character in the 
block not be a colon or consecutive colons, in 
character positions 9 and 10 of a central memory 
word. Two consecutive colons might be misinter¬ 
preted as a zero-byte terminator on a system using 
a 64-character set. 


QTRM (QTPUT) always adds a terminator for 6-blt 
display code data. If the program provides its own 
final line terminator for display-coded output, 
QTRM does not function in the same manner as it 
does for output transmissions occurring with a 
char-set field value of 2 or 3. No automatic 
terminator placement occurs during a QTPUT call 
involving those char-set field values. 


OUTPUT QUEUING USING QTRM 

Application programs commonly need to transmit more 
than one block in a message. If all of the con¬ 
nections serviced by the program have large values 
assigned for the abl parameter, no special program¬ 
ming is required. Most networks, however, use small 
values for the abl parameter. When a program using 
QTRM executes in such a network, it must use an 
output queue to store blocks ready for output when¬ 
ever the network does not permit immediate output 
of them. 

An output queue processor using QTRM can be coded 
according to the algorithm shown in figure 8-11. 
This algorithm uses the sleep field .parameter in 
the global portion of the network information table 
and depends on use of the current-abl parameter in 
the connection entry portion of the table. The 
following paragraphs explain the logic used to 
design the algorithm. 

When an application program services only one 
connection, the network can be made to cope with 
situations where the program produces output faster 
than a device can reproduce the output. The program 
sets the sleep parameter to a positive integer, and 
the network simply rolls the program out of central 
memory until the device catches up with the program. 

You cannot use the sleep parameter as a solution 
when the application program services more than one 
connection because the program is always rolled 
back in when input is available from any connection. 


Thus, input from device B brings the program back 
into central memory even though the output backlog 
for device A has not disappeared. A program serv¬ 
icing several connections always requires an output 
queuing algorithm that applies to each, when each 
connection potentially can be sent more than one 
block in a single message. 

Programs can also be coded for the opposite (type- 
ahead) environment, when the terminal user wants to 
enter many input messages and receive only one out¬ 
put transmission. Input queuing and support of 
typeahead are not discussed in this manual. Type- 
ahead can be supported without any interaction of 
an application program with the network protocol. 

The primary control variable of the output queuing 
algorithm is the connection number. Both the 
accompanying flow chart and the sample progam code 
depend on the use of the connection number field in 
conjunction with the connection entry fields of the 
network information table during the output queue 
scanning process. 

An application program can control the flow of its 
output to a specific connection by checking the 
current-abl field of the connection entry in the 
network information table before each QTPUT call 
Involving that connection. If the field contains a 
zero, the call cannot be made without violating 
network protocol; if the field does not contain a 
zero, the QTPUT call can be made. 


The current-abl, acknowledged-abn, and other fields 
in the network information table are only updated 
by QTRM during processing of a QTGET call. Tests 
of these fields are not meaningful unless a QTGET 
call is made before the tests. To properly control 
output flow, the application program must make 
periodic calls to QTGET with a positive value in the 
sleep field of the network information table, 
regardless of whether the program expects input 
from a connection. The size of the positive value 
is a tuning consideration determined by such things 
as the average length of output blocks and the 
speed of the device being serviced. 


These QTGET calls return control to the program 
after the sleep period. The program can then test 
the current-abl field and make any QTPUT calls that 
have become feasible. A QTPUT call is feasible 
whenever the current-abl value is nonzero. If the 
value is zero, another QTGET call must be made. 


An application program can use two forms of output 
flow control queuing. The program can actually 
generate all output required as a response to one 
input, then queue the output in large Internal buf¬ 
fers or disk files. This queued output is then 
spooled to the connection in QTPUT calls involving 
one or more lines in blocks up to the raax-block-size 
value for the connection entry in the network 
information table. The algorithm already described 
is used to control the occurrence of the QTPUT 
calls. 
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Figure 8-11. ALgorithm for Output Buffering Using QTRH 


Alternatively, the application program can queue 
its input requests. When the flow control algorithm 
described previously shows that a QTPUT call can be 
made, . the program can generate only enough output 
for one QTPUT call; After making the call, an 
uncompleted input request is returned to the queue 
to await additional processing the next time the 
flow control algorithm permits another QTPUT call 
for the connection. This approach requires a small 
input queue for each connection, but does not 
require large internal buffers for output storage. 

The second approach minimizes field length require¬ 
ments and mass storage access requirements for the 
program. Also, the program can avoid wasted output 
processing when the terminal user issues a user- 
break to terminate output after only one or two 
blocks of the output have been delivered. With the 


first approach, processing for the remainder of the 
output has already occurred and is wasted. With 
the second approach, no processing for the addi¬ 
tional output occurred and therefore the additional 
processing can be bypassed. 


DEBUGGING QTRM APPLICATION 
PROGRAMS 

All AIP debug features are available to QTRM 
application programs through calls to QTRM debug 
utility routines. These QTRM routines perform 
essentially the same function as the AIP routines 
to which they correspond. For more Information on 
debugging application programs, see section 6. 
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TURNING LOGGING OF NETWORK 
TRAFFIC ON/OFF (QTDBG) 

This QTRM utility routine allows the application 

program to turn on or turn off the logging of 

network data or supervisory message traffic. The 
call has the format shown in figure 8-12. 

RELEASING NETWORK DEBUG LOG FILE (QTREL) 

This QTRM utility routine allows the application 

program to route a Job to the input queue to 


release, save, or process the current information 
in the debug log file. To use this utility rou¬ 
tine, you must call it before you call QTOPEN. The 
job record from the file specified by the applica¬ 
tion program will be copied to the AIP debug log 
file. No job will be routed to the input queue on 
this initial call. Subsequent calls to QTREL 
result in the AIP debug log file being routed to 
the input queue and ,a new AIP debug log file 
created with a new job record from the file speci¬ 
fied by the application program. The call has the 
format shown in figure 8-13. 


ENTER FORTRAN-X QTDBG USING dbugsup,dbugdat,avaiL 


dbugsup An input parameter which turns the logging of supervisory messages on or off. In a COBOL call, 
this parameter is the Data Division descriptor for a level 01 data item. This parameter can 
have the values: 

=0 Turn supervisory message logging on. 

Turn supervisory message logging off. 

When supervisory message logging is turned on, all supervisory messages (except block- delivered 
messages) exchanged on connection zero between the application program and NAM are logged. 
Logging occurs whenever a call to QTGET, QTPUT, QTENDT, QTTIP, QTLEND, QTSUP, or QTLINK causes a 
message transfer. This logging continues until a call with a nonzero dbugsup parameter is 
issued. 

dbugdat An input parameter which turns the logging of data messages on or off. In a COBOL call, this 

parameter is the Data Division descriptor for a level 01 data item. This parameter can have the 
values: 

=0 Turn network data block Logging on. 

^0 Turn network data block logging off. 

When network data block logging is turned on, all network data blocks exchanged on any 
connection between the application program and NAM are Logged. Block-delivered supervisory 
messages CFC/ACK/R) are also logged, regardless of the value specified for the dbugsup 
parameter. Logging occurs whenever a call to QTGET or QTPUT causes a block transfer. This 
logging continues until a call with a nonzero dbugdat parameter is issued. 

avail A return parameter that indicates whether the Logging code portion of AIP was Loaded when the 

program was Loaded. In a COBOL call, this parameter is the Data Division descriptor for a level 
01 data item. On return from the call, this parameter can have the values: 

=0 Loading ocurred from NETIOD and logging is possible. 

=1 Loading occurred from NETIO and logging is not possible. 

When a value of 1 is returned, specification of 0 for either dbugsup or dbugdat has no effect 
but does not cause an error. 


Figure 8-12. QTDBG Statement COBOL Call Format 
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ENTER FORTRAN-X QTREL USING lfn,nsglth,nrewind 

Lfn 

An input parameter which names the 
file containing the job record to be 
copied to the AIP debug log file. In 
a COBOL call, this parameter is the 

Data Division descriptor for a level 

01 data item. This parameter can have 
the values: 


=0 The application program job 

provides its own disposi¬ 
tion of the AIP debug log 
file. Only the msglth 
parameter is processed by 
QTRM. 


The named file contains a 
job record to dispose of 
the AIP debug log file. 

The value declared for lfn 
must be left-justified with 
zero fill, and can be one 
to seven alphabetic or 
numeric characters in any 
combination permitted by 
the NOS operating system 
file name format. 

msglth 

An input parameter which gives the 
maximum number of words of each mes¬ 
sage to be saved on the AIP debug log 
file. In a COBOL call, this parameter 
is the Data Division descriptor for a 
level 01 data item. The value is 
ignored if msglth is zero. 

nrewind 

An input parameter which controls 
whether QTRM rewinds the job command 
record file before the QTREL operation 
begins. In a COBOL call, this param¬ 
eter is the Data Division descriptor 
for a level 01 data item. This param¬ 
eter can have the values: 


=0 File, lfn is rewound before 

any operation is performed. 


^<0 File lfn is not rewound 

before any operation is 
performed. 


If the value declared for lfn is zero, 
a value of zero for the rewind param¬ 
eter is ignored. 


FLUSH AlP DEBUG LOG FILE ON 
ABNORNMAL TERMINATION (QTSETF) 

This QTRM utility routine gives the application 
program a means of requesting the operating system 
to automatically flush the Input/output buffer for 
the debug log file, if the application program ter¬ 
minates abnormally. Application programs written 
in COBOL or FORTRAN should not call this utility 
program because it can affect the flushing of other 
files used by the application program. The call 
has the format shown in figure 8-14. 


ENTER 

FORTRAN-X 

QTSETF USING flush,fetadr 

flush 

An input parameter that automatically 
flushes the debug log file when abnor¬ 
mal termination occurs. The flush 
parameter can have the following 
values: 


=0 

The flush bit is set in the 

FET and the FET address of 
the debug log file is re¬ 
turned in fetadr. 


*0 

The flush bit is set in the 

FET and the SETLOF macro is 
called. The FET address is 
not returned. 

fetadr 

A return parameter that is the FET 
address of the debug log file returned 
to NAM. If zero, either the flush 
parameter was nonzero or NETIO was 
loaded (in which case, the flush param¬ 
eter makes no difference). 


Figure 8-14. QTSETF Statement COBOL 
Call Format 


ENTER MESSAGE INTO THE DEBUG 
LOG FILE (QTLOG) 

This QTRM utility routine allows the application 
program to enter formatted or unformatted messages 
into the AIP debug log file. QTLOG cannot be 
called before QTOPEN. The call has the format 
shown in figure 8-15. 


Figure 8-13. QTREL Statement COBOL 
Call Format 
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ENTER 

FORTRAN-X QTLOG USING wsa,size,format 

wsa 

An input parameter that is the message 
to be written to the debug Log file. 

In a COBOL call, this parameter is the 
Data Division descriptor for a Level OT 
data item. 

si ze 

An input parameter that gives the size 
in central memory words of the message 
to be written to the debug log file.' 

In a COBOL call, this parameter is the 
Data Division descriptor for a Level 01 
data item. 

format 

An input parameter that determines 
whether the message is formatted or 
unformatted. In a COBOL call, this 
parameter is the Data Division descrip¬ 
tor for a Level 01 data item. This 
parameter can have the values: 


=0 The message is unformatted 

and will be printed by DLFP 
in octal, hexadecimal, 6-bit 
display code characters, and 
ASCII characters. 


^0, The message is formatted and 

will be printed unchanged by 
DLFP. 


Figure 8-15. QTLOG Statement COBOL 
CaLl Format 


PERFORM BINARY DUMP OF 
APPLICATION (QTDMB) 

This QTRM utility routine allows the application 
program to dump its exchange package and central 
memory field length into the local dump file 
ZZZZDMB. The data is in binary format. 

The file ZZZZDMB must be postprocessed by a binary 
dump interpreter to allow selection of address 
range and formatting for print. The dump format¬ 
ting is done through DSDI, which is described in 


ENTER FORTRAN-X QTDMB USING dumpid,ecs 


dumpid An input parameter that is an octal 

6-digit dump identifier number. In a 
COBOL call, this parameter is the Data 
Division descriptor for a Level 01 data 
item. The dumpid parameter can have 
the values 0 through 777777. 

ecs An input parameter that determines 

whether the associated extended central 
storage is also dumped. In a COBOL 
call, this parameter is the Data Divi¬ 
sion descriptor for a level 01 data 
item. This parameter can have the 
values: 

=0 Do not dump extended central 

storage. 

i*0 Dump the associated extended 

central storage. 


Figure 8-16. QTDMB Statement COBOL 
Call Format 


the NOS 2 Analysis handbook. A logical end-or- 
record is written to the file ZZZZDMB after each 
QTDMB call. 

The call has the format shown in figure 8-16. 


TURNING LOGGING OF AlP STATISTICS 
ON/OFF (QTSTC) 

This QTRM utility routine allows the application 
program to turn on or off the logging of AIP 
statistics. The call has the format shown in 
figure 8-17. 

ENTER STATISTICAL MESSAGE INTO 
THE AIP STATISTICAL FILE (QTLGS) 

This QTRM utility routine allows the application 
program to enter display code messages into the AIP 
statistical log file. QTLGS cannot be called 
before QTOPEN. The call has the format shown in 
figure 8-18. 
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ENTER 

onoff 


aval I 


FORTRAN-X QTSTC USING onoff,avail 


An input parameter that turns the 
accumulation of statistics on or off. 

In a COBOL call, this parameter is the 
Data Division descriptor for a level 01 
data item. This parameter can have the 
values: 

=0 Turn accumulation on. 

=1 Turn accumulation off. 

When statistics accumulation is turned 
on, each call to a QTRM routine can 
result in different counters being 
incremented. Incrementing continues 
until a call with an onoff parameter of 
1 is issued. Calls with onoff param¬ 
eters of zero cause the counters to be 
flushed and reset to zero. 

A return parameter that indicates 
whether the statistical accumulation 
portion of AIP was loaded when the 
program was loaded. In a COBOL call, 
this parameter is the Data Division 
descriptor for a level 01 data item. 

On return from the call, this parameter 
can have the values: 

=0 Loading occurred from NETIOD 

and accumulation is possible. 

=1 Loading occurred from NETIO 

and accumulation is not 
possible. 

When a value of one is returned, speci¬ 
fication of zero in the onoff parameter 
has no effect but does not cause an 
error. 


ENTER FORTRAN-X QTLGS USING wsa,size 


wsa An input parameter that is the message 

to be written to the statistical log 
file. In a COBOL call, this parameter 
is the Data Division descriptor for a 
level 01 data item. The message must 
contain 6-bit display code information 
with a line terminator (12 to 66 bits 
of zero, right-justified in a central 
memory word). 

size An input parameter that gives the size 
in central memory words of the message 
to be written to the AIP statistical 
log file. In a COBOL call, this param¬ 
eter is the Data Division descriptor 
for a level 01 data item. 


Figure 8-18. QTLGS Statement COBOL 
Call Format 


SAMPLE PROGRAM 

Figure 8-19 contains the source code listing for a 
COBOL program that demonstrates use of QTRM in the 
simplest form possible. Program ECHO-EMV2 is simi¬ 
lar to the FORTRAN program RMV3 shown in section 
7. Both programs return to the terminal user each 
block entered from the device. Both programs queue 
output blocks and permit a prompting message to be 
output after each returned message. Both programs 
acknowledge entry of a user-break character with 
dialog. Both programs shut down operation after 
receiving a terminal operator command. 


Figure 8-17. QTSTC Statement COBOL 
Call Format 
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1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 
.32 
33 
.34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 


IDENTIFICATION DIVISION. 

PROGRAH-ID. ECH0-RWV2. 

ENVIRONMENT DIVISION. 

CONFIGURATION SECTION. 

INPUT-OUTPUT SECTION. 

FILE-CONTROL. 

DATA DIVISION. 

FILE SECTION. 

WORKING-STORAGE SECTION. 

01 NETWORK-INFORMATION-TABLE. 

02 GLOBAL-PORTION. 

03 APPLICATION-NAME PIC X(7). 

03 CHARACTER-SET PIC 9 COHP-4. 

03 NUMBER-CONNECTIONS PIC 999 COMP-4. 

03 NAM-SUPERVISOR-WORD PIC XCIO). 

03 FILLER PIC X(7). 

03 PARM-ADDRESS PIC 9(4) COHP-4. 

03 Q-DATA PIC 9 COMP-4. 

03 PARH-FLAG1 PIC 9 COHP-4. 

03 FILLER PIC X(5). 

03 SUB-RETURN-CODE PIC 999 COHP-4. 

03 APPLICATION-TO-APPLICATION PIC 9 COHP-4. 


*THE PICTURE SIZE USED FOR COMPUTATIONAL ITEMS SUCH AS 
*MAX-TRANS-SIZE AND SLEEP IS CHOSEN TO PERMIT STORAGE OF 
*THE LARGEST POSSIBLE FIELD VALUE WITHOUT TRUNCATION OF 
*THE VALUE DIGITS. 

* 


03 MAX-TRANS-SIZE PIC 999 COHP-4. 

03 MESSAGE-LENGTH PIC 999 COMP-4. 

03 SLEEP PIC S9 COMP-4. 

03 CONNECTION-NUMBER PIC 999 COMP-4. 

03 RETURN-CODE PIC 9 COHP-4. 

03 SECONDARY-RETURN-CODE PIC 9 COMP-4. 
03 INTERMEDIATE-MESSAGE PIC' 9 COHP-4. 

03 NEXT-APPLICATION-NAHE PIC XC7). 

03 X-SLEEP PIC S9(4) COHP-4. 

03 REQUESTED-APPLICATION-NAME PIC X(7). 
03 DESTINATION-HOST PIC X(3). 

03 TRUNCATE PIC 9 COMP-4. 

03 FILLER PIC X(6). 

03 LOGICAL-IDENTIFIER PIC X(3). 

03 FILLER PIC X(20). 

02 TERMINAL-ENTRY OCCURS 5 TIMES. 

03 TERMINAL-NAME PIC X(7). 

03 TERMINAL-CLASS PIC 9 COMP-4. 

03 PAGE-WIDTH PIC 999 COHP-4. 

03 FAMILY-NAME PIC X(7). 

03 DEVICE-TYPE PIC X. 

03 PAGE-LENGTH PIC 999 COHP-4. 

03 USER-NAME PIC X(7). 

03 SECURITY-LEVEL PIC 9 COMP-4. 

03 MAXIMUH-BLOCK-SIZE PIC 999 COMP-4. 

03 ABL PIC 9 COMP-4. 


COLUMN 1 2 3 4 5 6 7 8 
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Figure 8-19. Sample Program ECH0-RHV2 Source Listing (Sheet 1 of 14) 
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55 


03 CURRENT-ABN PIC 9(4) COHP-4. 




56 


03 ACKNOWLEDGED-ABN PIC 9(4) COMP-4. 




57 


03 STATE PIC 9 COMP-4. 




58 


03 LOANED-CONNECTION PIC 9 COHP-4. 




59 


03 CURRENT-ABL PIC 9 COHP-4. 




60 


03 FILLER PIC X(8). 




61 


03 SYNC-SH-CODE-SET PIC 9 COMP-4. 




62 


03 CONNECTION-INPUT-CODE-SET PIC 9 COMP-4. 




63 


03 UPLINE-ABH PIC XdO). 




64 


03 DOWNLINE-ABH PIC XdO). 




65 


03 FILLER PIC X(30). 




66 






67 

* 





68 

*THE FOLLOWING ARE OTRM SUBROUTINE PARAMETERS 




69 

* 





70 

01 

INCOMING. 




71 


02 COMMAND PIC X(20). 




72 


02 REST-OF-DATA PIC X(610). 




73 

01 

OUTGOING. 




74 


02 PRINT-CONTROL PIC X. 




75 


02 OUT-MESSAGE PIC X(630). 




76 

01 

COMMAND-CODE PIC 9(4) COHP-4. 




77 

01 

DBUGSUP PIC 9(4) COHP-4. 




78 

01 

DBUGDAT PIC 9(4) COHP-4. 




79 

01 

DUMPID PIC 9(5) COMP-4 VALUE IS ZEROES. 




80 

01 

ECS PIC 9(4) COHP-4 VALUE IS 1. 




81 

01 

ONOFF PIC 9(4) COMP-4. 




82 






83 

* 





84 

♦THESE 

ARE BLOCK QUEUE PROCESSING ITEMS. 




85 

* 





86 

01 

FOUND-FLAG PIC 9. 




87 

01 

QUEUE-SIZE PIC 99. 




88 






89 

-* 





90 

♦THIS 

IS A PUSHDOWN QUEUE USED TO STORE THOSE OUTPUT BLOCKS 




91 

♦THE PROGRAM TEMPORARILY CANNOT SEND TO THE TERMINAL 




92 

♦BECAUSE OF BLOCK LIMIT OR OTHER EVENTS IN THE NETWORK. 




93 

* 





94 






95 

01 

HOLDING-QUEUE. 




96 


02 QUEUE-ENTRY OCCURS 1 TO 60 TIMES DEPENDING ON 




97 


QUEUE-SIZE INDEXED BY INX-1 INX-2. 




98 


03 S-CONNECTION-NUMBER PIC 999 COHP-4. 




99 


03 S-HESSAGE PIC X(631). 




100 


03 S-INTERMEDIATE-MESSAGE PIC 9 COMP-4. 




101 






102 

* 





103 





104 






105 

PROCEDURE DIVISION. 




106 






107 

INITIALIZATION. 




108 







COLUMN 1 

2 3 4 5 6 

7 

8 
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Figure 8-19. ' Sample Program ECH0-RHV2 Source Li sting (Sheet 2 of 14) 
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109 

*SET UP AN ABORT RECOVERY PROCEDURE TO ENSURE DEBUGGING 



110 

*LOG FILE IS FLUSHED. USE THE FORTRAN 5 SUBROUTINE REPREV, 



111 

*AND RECOVER FROM ALL POSSIBLE ABORTS BY SETTING THE COMPLETE 



112 

•RECOVERY CONDITION MASK. AN INTERMEDIATE ROUTINE CALLED 



113 

•INSURE IS USED TO PASS THE ADDRESS OF ROUTINE TO RECOVR. 



114 

* 



115 

ENTER FTN5 INSURE. 



116 




117 

* 



118 

•HERE, THE NETWORK INFORMATION TABLE IS PRESET. 



119 

* 



120 

MOVE "RMV2" TO APPLICATION-NAME. 



121 

HOVE 4 TO CHARACTER-SET. 



122 

MOVE 631 TO HAX-TRANS-SIZE. 



123 




124 

★ 



125 

•THE FORMAT EFFECTOR CHARACTER CAUSES THE CURSOR TO 



126 

•RETURN TO THE LEFT EDGE OF THE SCREEN OR PAGE 



127 

•FOLLOWING THE CONTENTS OF OUT-MESSAGE. THIS ACTION 



128 

•LEAVES THE CURSOR POSITIONED SO THAT THE USER CAN ENTER 



129 

•A LINE EQUAL TO THE FULL PAGE WIDTH OF THE TERMINAL. 



130 

* 



131 




132 

HOVE TO PRINT-CONTROL. 



133 

HOVE SPACES TO OUT-MESSAGE. 


1 

134 

HOVE SPACES TO INCOMING. 



135 

HOVE 5 TO NUMBER-CONNECTIONS. 



136 

HOVE -1 TO SLEEP. 



137 

HOVE 0 TO PARH-ADDRESS. 



138 

HOVE 0 TO Q-DATA. 



139 

HOVE 0 TO PARH-FLA61. 



140 

MOVE -1 TO X-SLEEP. 



141 

HOVE 1 TO INTERMEDIATE-MESSAGE. 



142 

MOVE 0 TO QUEUE-SIZE. 



143 

MOVE 0 TO APPLICATION-TO-APPLICATION. 



144 

MOVE 0 TO FOUND-FLAG. 



145 

ENTER FORTRAN-X QTOPEN USING NETWORK-INFORHATION-TABLE. 



146 



147 




148 

•THE APPLICATION PROGRAM SHOULD BE NOTIFIED OF PRIORITY DATA. 



149 

* 



150 




151 

HOVE 2 TO COMMAND-CODE. 



152 

ENTER FORTRAN-X QTCMD USING COMMAND-CODE. 



153 




154 

* 



155 

•THE APPLICATION PROGRAM SHOULD BE NOTIFIED OF INACTIVE 



156 

•CONNECTIONS. 



157 

★ 



158 




159 

MOVE 3 TO COMMAND-CODE. 



160 

ENTER FORTRAN-X QTCMD USING COMMAND-CODE. 



161 




162 

* 
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163 

*ALL TERMINALS WILL BE SWITCHED AUTOMATICALLY TO lAF 




164 

*WHEN THEY ARE DISCONNECTED FROM THIS PROGRAM. 




165 

* 




166 





167 

MOVE "lAF" TO NEXT-APPLICATION-NAME. 




168 





169 





170 





171 





172 

MAIN-LOOP. 




173 

PERFORM RECEIVER THRU RECEIVE-EXIT. 




174 





175 

* 




176 

*IF NO CONNECTION, IGNORE. 




177 

* 




178 





179 

IF STATE (CONNECTION-NUMBER) = 0 




180 

GO TO MAIN-LOOP. 




181 





182 

* 




183 

*IF CONNECTION NOT INITIALIZED, IGNORE. 




184 

* 




185 





186 

IF STATE (CONNECTION-NUMBER) = 1 




187 

GO TO MAIN-LOOP. 




188 





189 

★ 




190 

*IF CONNECTION BEING ENDED, IGNORE. 




191 

* 




192 





193 

IF STATE (CONNECTION-NUMBER) = 11 




194 

GO TO MAIN-LOOP. 




195 





196 

* 




197 

*IF CONNECTION IS NEW AND INITIALIZED, SEND A BANNER. 




198 

* 




199 





200 

IF RETURN-CODE = 2 




201 

HOVE 0 TO INTERMEDIATE-MESSAGE 




202 

PERFORM DISPLAY-BANNER THRU BANNER-EXIT 




203 

GO TO MAIN-LOOP. 




204 





205 

* 




206 

•EITHER THE BLOCK LIMIT IS WRONG, OR A LOGIC ERROR EXISTS. 




207 

* 




208 





209 

IF RETURN-CODE = 5 




210 

PERFORM WHAT-HAPPENED. 




211 





212 

* 




213 

•CLEAN UP AFTER A LOST CONNECTION. 




214 

* 




215 





216 

IF RETURN-CODE = 6 
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217 

PERFORM CONNECTION-BROKEN-ROUTINE THRU CB-EXIT 





218 

60 TO MAIN-LOOP. 





219 






220 

* 





221 

★PROCESS A USER-BREAK-1 OR USER-BREAK-2 ENTRY. SCRAP ALL 





222 

★QUEUED OUTPUT. 





223 

* 





224 






225 

IF RETURN-CODE = 7 OR = 8 





226 

PERFORM FLUSH-QUEUE 





227 

HOVE 0 TO INTERMEDIATE-MESSAGE 





228 

MOVE TO PRINT-CONTROL 





229 

MOVE "NO ACTION TAKEN. NEXT ENTRY?" TO OUT-MESSAGE 





230 

PERFORM SENDER THRU SEND-EXIT 





231 

GO TO MAIN-LOOP. 





232 






233 

* 





234 

★NETWORK OR RMV2 SHOULD IDLE DOWN BY OPERATOR COMMAND. 





235 

* 





236 






237 

IF RETURN-CODE = 9 





238 

60 TO WRAP-UP. 





239 






240 

* 





241 

★OPERATOR SHUTDOWN OCCURRED. 





242 

* 





243 






244 

IF RETURN-CODE = 10 





245 

ENTER FORTRAN-X QTCLOSE 





246 

STOP RUN. 





247 






248 

* 





249 

★PROCESS PRIORITY DATA ENTRY. 





250 

* 





251 






252 

IF RETURN-CODE = 26 





253 

GO TO BYPASSED. 





254 






255 

* 





256 

★OPERATOR REQUESTED THAT DEBUG LOGGING BE STARTED. 





257 

* 





258 






259 

IF RETURN-CODE = 37 





260 

HOVE ZERO TO DBUGSUP 





261 

MOVE ZERO TO DBUGDAT 





262 

ENTER FORTRAN-X QTDB6 USING DBUGSUP, DBUGDAT 





263 

GO TO MAIN-LOOP. 





264 






265 

★ 





266 

★OPERATOR REQUESTED THAT FIELD LENGTH AND EXCHANGE PACKAGE 





267 

★BE DUMPED. 





268 

* 





269 






270 

IF RETURN-CODE = 36 




j 


COLUMN 1 2 3 4 5 6 

7 

8 




1234567890123456789Q123456789012345678901234567890123456789012345678901234567890 


_i 


Figure 8-19. Sample Program ECH0-RMV2 Source Listing (Sheet 5 of 14) 


8-46 


60499500 T 



CDC COBOL 5.3 - LEVEL 628 SOURCE LISTING OF ECHO-RH AOPT= 64/CDC/CDCS2 85/08/27. 14.07.49. 


271 


ADD 1 TO DUMPIO 

272 


ENTER FORTRAN-X QTDMB USING DUMPID, ECS 

273 


GO TO MAIN-LOOP. 

274 



275 

* 


276 

♦OPERATOR REQUESTED THAT DEBUG LOGGING BE STOPPED. 

277 

* 


278 



279 


IF RETURN-CODE = 38 

280 


MOVE 1 TO DBUGSUP 

281 


HOVE 1 TO DBUGDAT 

282 


ENTER FORTRAN-X QTDBG USING DBUGSUP, DBUGDAT 

283 


GO TO MAIN-LOOP. 

284 



285 

* 


286 

♦OPERATOR REQUESTED THAT STATISTICS COUNTERS BE RESET. 

287 

* 


288 



289 


IF RETURN-CODE = 39 

290 


MOVE ZERO TO ONOFF 

291 


ENTER FORTRAN-X QTSTC USING ONOFF 

292 


GO TO MAIN-LOOP. 

293 



294 

* 


295 

*THE 

OPERATOR’S REQUEST TO RELEASE THE LOG FILES FOR PROCESSING 

296 

♦CANNOT BE HONORED (A COBOL PROGRAM SHOULD NOT CALL QTREL) AND 

297 

♦IS 

IGNORED. 

298 

* 


299 



300 


IF RETURN-CODE = 40 

301 


GO TO MAIN-LOOP. 

302 



303 

* 


304 

♦NO 

TERMINAL ACTIVITY OCCURRED RECENTLY. DISCONNECT IT. 

305 

* 


306 



307 


IF RETURN-CODE = 42 

308 


MOVE TO PRINT-CONTROL 

309 


HOVE "TIME OUT" TO OUT-MESSAGE 

310 


PERFORM SENDER THRU SEND-EXIT 

311 


PERFORM END-CONNECTION THRU EC-EXIT 

312 


GO TO MAIN-LOOP. 

313 



314 

* 


315 

♦TO 

SIMPLIFY THE PROGRAM, ONLY EXPECTED CONDITIONS ARE PROCESSED 

316 

♦BY 

THE PRECEDING CODE. ALL OTHER CONDITIONS CAUSE THE PROGRAM 

317 

♦TO 

PLACE A DIAGNOSTIC MESSAGE IN THE FILE CALLED OUTPUT (WITH 

318 

♦THE 

DISPLAY STATEMENT) AND SHUT DOWN. NO DIAGNOSTIC APPEARS AT 

319 

♦THE 

TERMINAL. 

320 

♦ 


321 



322 


IF RETURN-CODE NOT = 0 

323 


DISPLAY "PROGRAM BUG OR OTHER ERROR" RETURN-CODE " " 

324 


SECONDARY-RETURN-CODE STOP RUN. 


COLUMN 1 2 3 4 5 6 7 8 

12345678901234567890123456789012345678901234567890123456789012345678901234567890 


Figure 8-19. Sample Program ECH0-RHV2 Source Listing (Sheet 6 of 14) 


PAGE 6 


60499500 T 


8-47 



CDC 

COBOL 5.3 - LEVEL 

628 SOURCE LISTING OF ECHO-RM AOPT= 64/CDC/CDCS2 85/08/27. 

14.07.49. 

PAGE 7 

325 





326 

* 




327 

♦INPUT 

PROCESSING BEGINS HERE, BY INITIALIZING OUTPUT. 



328 

♦POSSIBLE COMMANDS ARE THEN PROCESSED. 



329 

* 




330 





331 


HOVE TO PRINT-CONTROL. 



332 





333 

* 




334 

♦IF A 

TERMINAL USER ENTERS THE WORD END, THE USER IS 



335 

♦DISCONNECTED BUT THE PROGRAM CONTINUES TO SERVICE OTHER 



336 

♦TERMINALS. 



337 

* 




338 





339 


IF COMMAND = "END" 



340 


PERFORM END-CONNECTION THRU EC-EXIT 



341 


GO TO MAIN-LOOP. 



342 

4r 




343 

♦IF A 

TERMINAL USER ENTERS THE WORD SHUTDOWN, THE USER IS 



344 

♦DISCONNECTED AND THE PROGRAM SHUTS DOWN. 



345 

★ 




346 





347 


IF COMMAND = "SHUTDOWN" 



348 


HOVE 0 TO INTERMEDIATE-MESSAGE 



349 


MOVE "." TO PRINT-CONTROL 



350 


MOVE "BYE FOREVER!" TO OUT-MESSAGE 



351 


PERFORM SENDER THRU SEND-EXIT 



352 


GO TO WRAP-UP. 



353 





354 

•k 




355 

♦THE FOLLOWING CODE BEGINS THE INPUT-ECHOING PORTION 



356 

♦OF THIS PROGRAM. 



357 

* 




358 





359 


MOVE INCOMING TO OUT-MESSAGE 



360 


MOVE 1 TO INTERMEDIATE-MESSAGE 



361 


MOVE "." TO PRINT-CONTROL 



362 


PERFORM SENDER THRU SEND-EXIT 



363 





364 

■k 




365 

♦SEND 

PROMPT FOR NEXT LINE, WHICH ALSO ENDS PRESENT OUTPUT 



366 

♦MESSAGE TO THIS TERMINAL. 



367 

* 




368 





369 


MOVE 0 TO INTERMEDIATE-MESSAGE 



370 


HOVE "." TO PRINT-CONTROL 



371 


HOVE "NEXT ENTRY?" TO OUT-MESSAGE 



372 


PERFORM SENDER THRU SEND-EXIT 



373 


GO TO MAIN-LOOP. 



374 





375 

k 




376 

♦THIS 

ENDS THE MAIN PROGRAM PORTION OF ECH0-RMV2. THE FOLLOWING 



377 

♦PARAGRAPHS COMPRISE THE SUBROUTINES USED BY THE MAIN PROGRAM. 



378 

k 
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379 

*************************************************************** 



380 




381 

RECEIVER. 



382 

IF QUEUE-SIZE = 0 



383 

HOVE -1 TO SLEEP 



384 




385 

* 



386 

*THE NEXT LINE PREVENTS LEFTOVER CHARACTERS FROH THE END OF THE 



387 

*LAST INPUT LINE FROM BEING INCLUDED IN THE TRANSFER OF THE 



388 

^CURRENT (AND PRESUMABLY SHORTER) LINE. 



389 

* 



390 




391 

HOVE SPACES TO INCOMING 



392 

ENTER FORTRAN-X QTGET USING INCOMING 



393 

GO TO RECEIVE-EXIT. 



394 

HOVE 1 TO SLEEP 



395 

HOVE SPACES TO INCOMING 



396 

ENTER FORTRAN-X QTGET USING INCOMING. 



397 

IF RETURN-CODE NOT = 1 



398 

GO TO RECEIVE-EXIT 



399 

ELSE NEXT SENTENCE. 



400 




401 

QUEUE-OUTPUT-CODE. 



402 

MOVE 0 TO FOUND-FLAG. 



403 

PERFORM QUEUE-SCAN VARYING INX-1 FROH 1 BY 1 



404 

UNTIL FOUND-FLAG = 1 OR INX-1 EXCEEDS QUEUE-SIZE. 



405 

IF FOUND-FLAG = 0 



406 

GO TO RECEIVER 



407 

ELSE NEXT SENTENCE. 



408 

SET INX-1 DOWN BY 1. 



409 

* 



410 

*THE REMAINING CODE ATTEMPTS TO REMOVE ALL 



411 

♦QUEUED OUTPUT FROM THE OUTPUT QUEUE, ONE ENTRY AT A 



412 

♦TIME, REGARDLESS OF CONNECTION NUMBER. EACH SEND 



413 

♦OPERATION IS FOLLOWED BY A RETURN TO THE POINT IN 



414 

♦THE PROGRAM WHERE STATUS UPDATES ARE OBTAINED. 



415 

★ 



416 




417 

HOVE S-INTERMEDIATE-MESSAGE (INX-1) TO 



418 

INTERMEDIATE-MESSAGE. 



419 

MOVE S-CONNECTION-NUMBER (INX-D TO CONNECTION-NUMBER. 



420 




421 

IF STATE (CONNECTION-NUMBER) = 8 



422 

GO TO RECEIVE-EXIT. 



423 

IF STATE (CONNECTION-NUMBER) = 10 



424 

GO TO RECEIVE-EXIT. 



425 

IF STATE (CONNECTION-NUMBER) = 11 



426 

GO TO RECEIVE-EXIT. 



427 




428 

HOVE TO PRINT-CONTROL. 



429 

MOVE S-HESSAGE (INX-1) TO OUT-MESSAGE. 



430 

PERFORM QUEUE-COMPRESSION VARYING INX-2 FROH INX-1 BY 1 



431 

UNTIL INX-2 = QUEUE-SIZE. 



432 

SUBTRACT 1 FROH QUEUE-SIZE. 
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433 

434 

435 

436 

437 

438 

439 

440 

441 

442 

443 

444 

445 

446 

447 

448 

449 

450 

451 

452 

453 

454 

455 

456 

457 

458 

459 

460 

461 

462 

463 

464 

465 

466 

467 

468 

469 

470 

471 

472 

473 

474 

475 

476 

477 

478 

479 

480 

481 

482 

483 

484 

485 

486 


PERFORM SENDER THRU SEND-EXIT. 

IF QUEUE-SIZE = 0 
GO TO RECEIVER 

ELSE GO TO QUEUE-OUTPUT-CODE. 

RECEIVE-EXIT. 

EXIT. 


QUEUE-SCAN. 

MOVE S-CONNECTION-NUMBER <1NX-1) TO CONNECTION-NUMBER. 
IF CURRENT-ABL (CONNECTION-NUMBER) EXCEEDS 0 
MOVE 1 TO FOUND-FLAG. 

QUEUE-COMPRESSION. 

MOVE QUEUE-ENTRY (INX-2 + 1) TO QUEUE-ENTRY (INX-2). 

FLUSH-QUEUE. 

SET INX-1 INX-2 TO 1. 

PERFORM FLUSH-LOOP UNTIL INX-2 EXCEEDS QUEUE-SIZE. 

SET INX-1 DOWN BY 1. 

SET QUEUE-SIZE TO INX-1. 

FLUSH-LOOP. 

IF S-CONNECTION-NUMBER (INX-1) = CONNECTION-NUMBER 
SET INX-2 UP BY 1 
ELSE 

PERFORM CONDITIONAL-QUEUE-MOVE 
SET INX-1 INX-2 UP BY 1. 

CONDITIONAL-QUEUE-MOVE. 

IF INX-1 NOT = INX-2 

MOVE QUEUE-ENTRY (IMX-2) TO QUEUE-ENTRY (INX-1). 


SENDER. 

IF CURRENT-ABL (CONNECTION-NUMBER) = 0 

PERFORM PUSH-DOWN-QUEUE GO TO SEND-EXIT. 


* 

★THE PROGRAM HAS QTRH SCAN BACKWARDS THROUGH THE MESSAGE 
★AREA AND TRUNCATE THE MESSAGE AUTOMATICALLY. THIS PROCEDURE 
★IS COMPARABLE TO THE ONE USED BY CYBER RECORD MANAGER FOR 
★Z-TYPE RECORDS. 

* 


MOVE 0 TO MESSAGE-LENGTH. 

ENTER FORTRAN-X QTPUT USING OUTGOING. 


* 

★IF NAM HAS STOPPED OUTPUT ON THE CONNECTION TEMPORARILY, OR IF 
★THE BLOCK LIMIT HAS BEEN EXCEEDED (AN EVENT THAT SHOULD NOT 
★HAPPEN) FOR THE CONNECTION, THE MESSAGE IS RETURNED TO THE 
★QUEUE FOR A LATER TRY. 
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IF RETURN-CODE = 5 

PERFORM WHAT-HAPPENEO. 


SEND-EXIT. 

EXIT. 


PUSH-DOWN-OUEUE. 

ADD 1 TO QUEUE-SIZE. 

IF QUEUE-SIZE EXCEEDS 60 DISPLAY "QUEUE OVERFLOW ABORT" 
PERFORM DUMPER THRU DUMPER-EXIT VARYING INX-1 FROM 
1 BY 1 UNTIL INX-1 EXCEEDS 60 
STOP RUN. 

MOVE INTERMEDIATE-MESSAGE TO S-INTERMEDIATE-MESSAGE 
(QUEUE-SIZE). 

MOVE CONNECTION-NUMBER TO S-CONNECTION-NUMBER (QUEUE-SIZE), 
MOVE OUT-MESSAGE TO S-MESSAGE (QUEUE-SIZE). 


*THE FOLLOWING PROMPT IS MANDATORY, BECAUSE QTRM DOES NOT 
♦AUTOMATICALLY ISSUE A PROMPT TO A NEW 
♦CONNECTION TO INITIALIZE THAT CONNECTION. THE FOLLOWING 
♦PROMPT IS SENT BECAUSE GOOD PROGRAMMING PRACTICE 
♦REQUIRES A NETWORK APPLICATION PROGRAM TO IDENTIFY ITSELF 
♦TO A TERMINAL USER. 


DISPLAY-BANNER. 

MOVE TO PRINT-CONTROL. 

MOVE "THIS IS RMV2 USING QTRM. ENTER SOMETHING." TO 
OUT-MESSAGE. 

PERFORM SENDER THRU SEND-EXIT. 

BANNER-EXIT. 

EXIT. 


♦NO CALL TO QTENDT IS NECESSARY DURING THIS PROCESSING BRANCH, 
♦BECAUSE QTRM AUTOMATICALLY CLEANS UP THE CONNECTION WHEN IT 
♦RETURNS THE CONNECTION-BROKEN STATUS. 


CONNECTION-BROKEN-ROUTINE. 

DISPLAY "CONNECTION BROKEN - TERMINAL USER HUNG UP 
CONNECTION-NUMBER 

DISPLAY " FAMILY " FAMILY-NAME (CONNECTION-NUMBER) 
DISPLAY " USER " USER-NAME (CONNECTION-NUMBER). 


CB-EXIT. 

EXIT. 
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541 

* 




542 

*THE WAIT-FOR-QUIET CALLS PROVIDE A DELAY FOR THE 




543 

★NETWORK TO CLEAN UP ALL OUTSTANDING SUPERVISORY MESSAGE 




544 

★TRAFFIC RELATED TO THE SHUTDOWN. WITHOUT THIS DELAY, 




545 

★SOME TERMINAL CONNECTIONS WOULD RECEIVE AN 




546 

★"APPLICATION FAILED" MESSAGE. 




547 

★ 




548 





549 

WRAP-UP. 




550 

PERFORM GRACEFUL-DISCONNECTS THRU GD-EXIT VARYING 




551 

CONNECTION-NUMBER 




552 

FROM 1 BY 1 UNTIL CONNECTION-NUMBER = 6. 




553 

ENTER FORTRAN-X OTCLOSE. 




554 

STOP RUN. 




555 





556 

GRACEFUL-DISCONNECTS. 




557 

IF STATE (CONNECTION-NUMBER) = 2 




558 

PERFORM FLUSH-OUEUE 




559 

MOVE 0 TO INTERMEDIATE-MESSAGE 




560 

MOVE TO PRINT-CONTROL 




561 

MOVE "SHUTDOWN COMING" TO OUT-MESSAGE 




562 

PERFORM SENDER THRU SEND-EXIT 




563 

ENTER FORTRAN-X OTENDT. 




564 





565 

IF RETURN-CODE = 22 




566 

DISPLAY "PROGRAM BUG OR OTHER ERROR" RETURN-CODE " 

II 



567 

SECONDARY-RETURN-CODE STOP RUN. 




568 





569 

GD-EXIT. 




570 

EXIT. 




571 





572 

END-CONNECTION. 




573 

PERFORM FLUSH-QUEUE 




574 

MOVE 0 TO INTERMEDIATE-MESSAGE 




575 

MOVE "." TO PRINT-CONTROL 




576 

MOVE "GOODBYE FOR NOW.." TO OUT-MESSAGE. 




577 

PERFORM SENDER THRU SEND-EXIT. 




578 

ENTER FORTRAN-X QTENDT. 




579 

IF RETURN-CODE = 22 




580 

DISPLAY "PROGRAM BUG OR OTHER ERROR" RETURN-CODE " 

II 



581 

SECONDARY-RETURN-CODE STOP RUN. 




582 





583 

EC-EXIT. 




584 

EXIT. 




585 





586 

DUMPER. 




587 

DISPLAY S-CONNECTION-NUMBER (INX-1) 




588 

S-MESSAGE (INX-1). 




589 





590 

DUMPER-EXIT. 




591 

EXIT. 




592 





593 





594 

BYPASSED. 
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595 


HOVE 0 TO INTERMEDIATE-MESSAGE. 




596 


MOVE TO PRINT-CONTROL. 




597 


HOVE "CHARACTER BYPASSED INPUT" TO OUT-MESSAGE. 




598 


PERFORM SENDER THRU SEND-EXIT. 




599 


GO TO MAIN-LOOP. 




600 






601 


BYPASSEO-EXIT. 




602 


EXIT. 




603 






604 






605 


HHAT-HAPPENED. 




606 


IF SECONDARY-RETURN-CODE = 21 




607 


PERFORM PUSH-DOWN-QUEUE 




608 


GO TO MAIN-LOOP. 




609 






610 


IF SECONDARY-RETURN-CODE NOT = 21 




611 


DISPLAY "PROGRAM BUG OR OTHER ERROR" RETURN-CODE " 

tt 



612 


SECONDARY-RETURN-CODE. 




613 






614 


STOP RUN. 
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SUBROUTINE INSURE 

74/835 0PT=0,R0UND= A/ S/ H/-D,-DS - FTN 5.1+628 85/08/27. 14.08.56 PAGE 1 

D0=-L0NG/-0T,ARG=- 

-COHHON/-FIXED,CS= USER/-FIXED,OB=-TB/-SB/-SL/ ER/-ID/-PHD/-ST,-AL,PL=5000 

FTN5,I=RMV2,L=0UTPUT. 

1 

SUBROUTINE INSURE 

2 

EXTERNAL REPREV 

3 

C0NDITN=0"277" 

4 

CHKSUH=0 

5 

CALL RECOVR (REPREV,CONDITN,CHKSUH) 

6 

RETURN 

7 

END 

—VARIABLE HAP—CL0=A) 


-NAHE-ADDRESS —BLOCK— 

-PROPERTIES-TYPE-SIZE 

CHKSUH 26B 

REAL 

CONDITN 258 

REAL 

—PROCEDURES— (L0=A) 


-NAHE-TYPE-ARCS-CLASS- 

RECOVR 

3 SUBROUTINE 

REPREV UNKNOWN EXTERNAL 

—ENTRY POINTS—{LO=A) 


-NAHE-ADDRESS—ARCS 


INSURE SB 0 


—STATISTICS— 


PROGRAH-UNIT LENGTH 

27B = 23 

CH STORAGE USED 

63200B = 26240 

COHPILE TIHE 

0.014 SECONDS 


Figure 8-19. Sample Program ECH0-RMV2 Source Listing (Sheet 13 of 14) 
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SUBROUTINE REPREV 74/835 0PT=0,R0UN0= A/ S/ M/-D,-DS FTN 5.1+628 85/08/27. 14.08.56 PAGE 1 
DO=-LONG/-OT,ARG=-COMHON/-FIXED,CS= USER/-FIXED,DB=-TB/-SB/-SL/ ER/-I0/-PMD/-ST,-AL,PL=5000 
FTN5,I=RHV2,L=0UTPUT. 


1 SUBROUTINE REPREV (IXCHNG,IFLA6,IFLDLN) 

2 DIMENSION IXCHNGC26),IFLDLNX0"72200") 

3 IFLA6=1 

4 CALL OTCLOSE 

5 END 


--VARIABLE HAP—(LO=A) 


■NAME-ADI 

IFLAG 

>RESS 

2 

—BLOCK- 

DUMMY-ARG 

•PROPERTIES-TYPE- 

INTEGER 

—SIZE 

IFLDLN 

3 

DUNMY-ARG 

INTEGER 

29824 

IXCHNG 

1 

DUMMY-ARG 

INTEGER 

26 


—PROCEDURES— (LO=A) 

-NAME-TYPE-ARGS-CLASS- 

GTCLOSE 0 SUBROUTINE 


—ENTRY POINTS—(LO=A) 
-NAME-ADDRESS—ARGS- 

REPREV 68 3 


—STATISTICS— 

PROGRAH-UNIT LENGTH 23B = 19 

CM STORAGE USED 63200B = 26240 

COMPILE TIME 0.018 SECONDS 


Figure 8-19. Sample Program ECH0-RMV2 Source Listing (Sheet 14 of 14) 


Figure 8-20 shows the commands used to execute 
ECHO-RMV2. ECHO-RMV2 exists as an Indrect access 
source code file named RMV2. 

Figure 8-21 contains a complete dehug log file 
listing for a single execution of ECHO-RMV2. This 
log file Is very similar to the one shown In sec¬ 
tion 7 for program RMV3 because both programs use 
essentially the same AIP routines for the same 
functions and support the same kind of dialog. 

Figure 8r22 contains a statistics file listing for 
ECH0-RMV2. 

Figure 8-23 is a console printer.listing for. two 
sequential connections using ECHO-RMV2 during a 
single execution of that program. The listing Figure 8-20. ECH0-RHV2 Job Commands 

Includes program-generated messages and a console 
Input message that Is echoed back. 
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85/08/27 
PAGE 00001 

14.09.14.000 NETON (015720) ANAHE = RHV2 DATE = 85/08/27 MSG NO. 000001 

NSUP ADDR = 002211 MINACN =00001 HAXACN =00005 


14.11.06.199 NET6ET (016407) ACN =0000 HA =013520 TA =013561 TLHAX =0063 MSG NO. 000002 

AST =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0011 

001 630000001400700 30600000000120003400 CONREQ C P 
002 51C7A00EDB45013 24343640035555050023 T135C E S Z H4P 

003 000000000000758 00000000000000003530 2X U 

004 0000000002EB009 00000000000013530011 K$ I .0 

005 XXXXXXX13B40013 xxxxxxxxxx2355000023 xxxxxx S HC. A;a 

006 XXXXXXX21B4052E xxxxxxxxxxxx55002456 xxxxxx T, 4 UX!4 . 

007 000FF8FFFFFFFFF 00007770777777777777 X 

008 FFDFCOOOOFFFFFF 77757700000077777777 ; ; ;;;; 3 

009 000000002E78BEF 00000000000271705757 B?’.. .X> 

010 7C01403C530F14C 37000500170514170514 4 E OELOEL wa EOGL 

011 000000000000000 00000000000000000000 


14.11.06.199 NETPUT (016735) HA =013520 TA =013561 MSG NO. 000003 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 634000001400901 30640000000120004401 CONREQN Ca 


14.11.08.595 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000004 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830700001000000 40603400000100000000 FCINIT 


14.11.08.595 NETPUT (016735) HA =013520 TA =013561 MSG NO. 000005 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 834700001000000 40643400000100000000 FCINITN G 


14.11.08.597 NETPUT (016735) HA =013520 TA =002403 MSG NO. 000006 

ABT =02 ADR =0001 ABN =000001 ACT =04 STATUS = 00000000 TLC = 0050 

001 BD42094ED253B52 57241011235511235522 .THIS IS R =B NRS5 
002 35676D55324E1ED 15263555252311160755 HV2 USING #VVUS$AM 
003 45448DBED14E505 21242215575505162405 OTRM. ENTE ED >8NP 
004 4AD4CF34550824E 22552317150524101116 R SOMETHIN T-LSEP N 
005 1EFOOOOOOOOOOOO 07570000000000000000 G. P 


14.11.11.195 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000007. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000040 40601000000100000100 FCACK 


Figure 8-21. Debug Log File Listing for ECH0-RHV2 (Sheet 1 of 9) 


RHV2 LOG FILE OUTPUT 
DATE RECORDED - 85/08/27 
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RMV2 LOG FILE OUTPUT 
DATE RECORDED - 85/08/27 


85/08/27 
PAGE 00002 


14.11.27.491 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLMAX =0063 HSG NO. 

ABT =02 ADR =0001 ABN =000000 ACT =04 STATUS = 00000000 TLC = 0047 


001 50816D385614B43 
002 201481004152849 
003 4ED06D553152982 
004 48504B99DB43201 
005 4810D4152BC0000 


24100555160530245503 

10012201032405225511 

23550155252305224602 

22050113463555031001 

22010324052257000000 


THE NEXT C P M8V 4 
HARACTER I 2 H T +I 
S A USER-B NPHUIR 
REAK-2 CHA $ 9 42 
RACTER. H T +3 


14.11.27.493 NETPUT (016735) HA =013520 TA =002403 MSG NO. 

ABT =01 ADR =0001 ABN =000002 ACT =04 STATUS = 00000000 TLC = 0050 


001 BD4205B4E15852D 57241005551605302455 
002 0C80520435054AD 03100122010324052255 
003 253B41B554C54A6 11235501552523052246 
004 0921412E676D0C8 02220501134635550310 
005 0520435054AF000 01220103240522570000 


.THE NEXT 
CHARACTER 
IS A USER- 
BREAK-2 CH 
ARACTER. 


=B 4AXR 
PH CPT- 
%;A5TEJ 
a FVPH 
CPT/ 


14.11.27.495 NETPUT (016735) HA =013520 TA =002403 HSG NO. 

ABT =02 ADR =0001 ABN =000003 ACT =04 STATUS = 00000000 TLC = 0020 

001 BCE15852D14E512 57160530245505162422 .NEXT ENTR <AXRQNa 
002 679000000000000 31710000000000000000 Y? 8Y 


14.11.29.554 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 HSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000080 40601000000100000200 FCACK 


14.11.29.555 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 HSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001OOOOCO 40601000000100000300 FCACK 


14.11.39.236 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 HSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 800004001000000 40000004000100000000 INTRUSR 


14.11.39.237 NETPUT (016735) HA =013520 TA =013561 HSG NO. 

ABT =03 ADR =0001 ABN =000004 ACT =02 STATUS = 00000000 TLC = 0002 

001 CBOOOOOOOOOOOOO 62600000000000000000 ROHARK K 


14.11.39.237 NETPUT (016735) HA =013520 TA =013561 MSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


Figure 8-21. Debug Log File Listing for ECH0-RMV2 (Sheet 2. of 9) 
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RMV2 LOG FILE OUTPUT 85/08/27 

DATE RECORDED - 85/08/27 PAGE 00003 


001 800100001000000 40000400000100000000 INTRRSP 


14.11.39.239 NETPUT (016735) HA =013520 TA =002403 MSG NO. 000016 

ABT =02 ADR =0001 ABN =000005 ACT =04 STATUS = 00000000 TLC = 0040 

001 BCE3ED0435093CE 57161755010324111716 .NO ACTION <CM 5 < 

002 B5404B14EBED385 55240113051657551605 TAKEN. NE KT 1N>S 
003 614B45394499E40 30245505162422317100 XT ENTRY? AKE9D D 
004 000000000000000 00000000000000000000 


14.11.39.243 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLHAX =0063 MSG NO. 000017 

ABT =03 ADR =0001 ABN =000000 ACT =02 STATUS = 00000000 TLC = 0002 

001 CA0000003401390 62400000000320011620 35 CPANP J 4 9 


14.11.40.277 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLHAX =0063 MSG NO. 000018 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000100 40601000000100000400 FCACK 


14.11.40.277 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000019 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000140 40601000000100000500 FCACK 


14.12.06.492 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLHAX =0063 MSG NO. 000020 

ABT =02 ADR =0001 ABN =000000 ACT =04 STATUS = 00000000 TLC = 0047 

001 50816D385614B43 24100555160530245503 THE NEXT C P H8V 4 

002 2014810D4152B49 10012201032405225511 HARACTER I 2 H T +I 

003 4ED06D553152982 23550155252305224602 S A USER-B NPMU1R 

004 48504B99CB43201 22050113463455031001 REAK-1 CHA $ 9 42 

005 4810D4152BC0000 22010324052257000000 RACTER. H T +a 


14.12.06.494 NETPUT (016735) HA =013520 TA =002403. MSG NO. 000021 

ABT =01 ADR =0001 ABN =000006 ACT =04 STATUS = 00000000 TLC = 0050 

001 BD4205B4E15852D 57241005551605302455 .THE NEXT =B 4AXR 

002 0C80520435054AD 03100122010324052255 CHARACTER PH CPT- 

003 253B41B554C54A6 11235501552523052246 IS A USER- %;A5TEJ 

004 0921412E672D0C8 02220501134634550310 BREAK-1 CH 3 FRPH 

005 0520435054AF000 01220103240522570000 ARACTER. CPT/ 


14.12.06.498 NETPUT (016735) HA =013520 TA =002403 MSG NO. 000022 

ABT =02 ADR =0001 ABN =000007 ACT =04 STATUS = 00000000 TLC = 0020 


Figure 8-21. Debug Log File Listing for ECH0-RHV2 (Sheet 3 of 9) 
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RHV2 LOG FILE OUTPUT 
DATE RECORDED - 85/08/27 

001 BCE15852D14E512 57160530245505162422 .NEXT ENTR <AXRQNCI 
002 679000000000000 31710000000000000000 Y? 8Y 


14.12.07.554 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLHAX =0063 MSG NO. 000023 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000180 40601000000100000600 FCACK 


14.12.07.554 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000024 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 8302000010001 CO 40601000000100000700 FCACK 


14.12.10.464 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLHAX =0063 MSG NO. 000025 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 800003001000000 40000003000100000000 INTRUSR 


14.12.10.464 NETPUT (016735) HA =013520 TA =013561 MSG NO. 000026 

ABT =03 ADR =0001 ABN =000008 ACT =02 STATUS = 00000000 TLC = 0002 

001 CBOOOOOOOOOOOOO 62600000000000000000 ROHARK K 


14.12.10.464 NETPUT (016735) HA =013520 TA =013561 MSG NO. 000027 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 800100001000000 40000400000100000000 INTRRSP 


14.12.10.467 NETPUT (016735) HA =013520 TA =002403 MSG NO. 000028 

ABT =02 ADR =0001 ABN =000009 ACT =04 STATUS = 00000000 TLC = 0040 

001 BCE3ED0435093CE 57161755010324111716 .NO ACTION <CM 5 < 

002 B5404B14EBED385 55240113051657551605 TAKEN. NE_ KT 1N>S 
003 614B45394499E40 30245505162422317100 XT ENTRY? AKE9D D 
004 000000000000000 00000000000000000000 


14.12.10.471 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLHAX =0063 MSG NO. 000029 

ABT =03 ADR =0001 ABN =000000 ACT =02 STATUS = 00000000 TLC = 0002 

001 CA0000003401390 62400000000320011620 35 CPANP J 49 


14.12.11.484 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000030 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000200 40601000000100001000 FCACK 


Figure 8-21. Debug Log File Listing for ECH0-RMV2 (Sheet 4 of 9) 
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PAGE 00004 
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RHV2 LOG FILE OUTPUT 85/08/27 

DATE RECORDED - 85/08/27 PAGE 00005 


14.12.11.484 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000031 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000240 40601000000100001100 FCACK $ 


14.12.16.197 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLMAX =0063 MSG NO. 000032 

ABT =02 ADR =0001 ABN =000000 ACT =04 STATUS = 00000000 TLC = 0003 

001 14E100000000000 05160400000000000000 END A 


14.12.16.199 NETPUT (016735) HA =013520 TA =002403 MSG NO. 000033 

ABT =02 ADR =0001 ABM =000010 ACT =04 STATUS = 00000000 TLC = 0020 

001 BC73CF102645B46 57071717040231055506 .GOODBYE F <S0 &E4 
002 3D2B4E3D7BEF000 17225516172757570000 OR NOW.. CR4CW>P 


14.12.16.200 NETPUT (016735) HA =013520 TA =013561 MSG NO. 000034 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 C00000001000000 60000000000100000000 LSTOFF a 


14.12.16.200 NETPUTF (016753) HA =013520 NA =001 TAA =013660 MSG NO. 000035 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0002 

FRAGMENT 001 SIZE =0002 ADDRESS = 013561 

001 630600001000000 30603000000100000000 X#X A C 
002 2411ADB6DB40000 11010655555555000000 lAF A CH4 


14.12.16.455 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000036 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 634600001000000 30643000000100000000 CONENDN CF 


14.13.02.594 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000037 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0011 


001 630000001400700 30600000000120003400 CONREQ C P 
002 51C7A00EDB45013 24343640035555050023 T135C E S Z M4P 

003 000000000000758 00000000000000003530 2X U 

004 0000000002EB009 00000000000013530011 K$ I .0 

005 XXXXXXX13B40013 xxxxxxxxxx2355000023 xxxxxx S HC A;a 

006 XXXXXXXXXB4052E xxxxxxxxxxxx55002456 xxxxxx T, 4 UX!4 . 

007 000FF8FFFFFFFFF 00007770777777777777 X_ 

008 FFDFCOOOOFFFFFF 77757700000077777777 ; ; ;;;; ] _ 

009 000000002E78BEF 00000000000271705757 B?'.. .X> 

010 7C01403C530F14C 37000500170514170514 4 E OELOEL Wa EOQL 
011 000000000000000 00000000000000000000 


Figure 8-21. Debug Log File Listing for ECH0-RMV2 (Sheet 5 of 9) 


8-60 


60499500 T 





RMV2 LOG FILE OUTPUT 
DATE RECORDED - 85/08/27 


85/08/27 
PAGE 00006 


14.13.02.594 HETPUT (016735) HA =013520 TA =013561 WSG NO. 000038 

AST =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 634000001400901 30640000000120004401 CONREQN ca 


14.13.04.219 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000039 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830700001000000 40603400000100000000 FCINIT 


14.13.04.219 NETPUT (016735) HA =013520 TA =013561 MSG NO. 000040 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 834700001000000 40643400000100000000 FCINITN G 


14.13.04.221 NETPUT (016735) HA =013520 TA =002403 HSG NO. 000041 

ABT =02 ADR =0001 ABN =000001 ACT =04 STATUS = 00000000 TLC = 0050 

001 BD42094ED253B52 57241011235511235522 .THIS IS R =B NRS5 

002 35676D55324E1ED 15263555252311160755 HV2 USING #VVUS$AH 

003 45448DBED14E505 21242215575505162405 QTRH. ENTE ED >QNP 

004 4AD4CF34550824E 22552317150524101116 R SOMETHIN T-LSEP N 

005 1EFOOOOOOOOOOOO 07570000000000000000 G. P 


14.13.05.528 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 000042 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000040 40601000000100000100 FCACK 


14.15.41.726 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLMAX =0063 HSG NO. 000043 

ABT =01 ADR =0001 ABN =000000 ACT =04 STATUS = 00000000 TLC = 0100 

001 508253B494ED06D 24101123551123550155 THIS IS A P S4 H 

002 51940504814112D 24312005011005010455 TYPEAHEAD U aPH - 

003 5054D4BAD14E505 24052324565505162405 TEST, ENTE PTT QNP 
004 489387B414ED355 22111607550123551525 RING AS MU T 8CANSU 

005 0C8B5415852D053 03105524053024550123 CH TEXT AS T - 

006 B503D34C908C16D 55201723231102140555 POSSIBLE ;P=4I AM 
007 50FB430554C5355 24175503012523051525 TO CAUSEHU PCC TE5 

008 314250305B4E154 14241120140555160524 LTIPLE NET S % 4AT 

009 5CF48BB4230F0CB 27172213550214170313 WORK BLOCK T 4# 

010 4ED550309385B54 23552520141116055524 S UPLINE T 4HU 8CT 


14.15.41.728 NETPUT (016735) HA =013520 TA =002403 HSG NO. 000044 

ABT =01 ADR =0001 ABN =000002 ACT =04 STATUS = 00000000 TLC =0110 


Figure 8-21. Debug Log File Listing for ECH0-RMV2 (Sheet 6 of 9) 
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RHV2 LOG FILE OUTPUT 





85/08/27 



DATE RECORDED - 85/08/27 





PAGE 00007 

001 

BD42094ED253B41 

57241011235511235501 .THIS IS A 

=B NRS4 






002 

B54650141205044 

55243120050110050104 TYPEAHEAD 

TE A PD 






003 

B5415352EB45394 

55240523245655051624 TEST, ENT 

5ASRKE9 






004 

15224E1ED053B4D 

05221116075501235515 ERING AS M 

AR$AM ;M 






005 

54322D505614B41 

25031055240530245501 UCH TEXT A 

T2-PV 4 






006 

4ED40F4D3242305 

23552017232311021405 S POSSIBLE 

MBTSS# 






007 

B543ED0C155314D 

55241755030125230515 TO CAUSEH 

5CH S 






008 

54C50940C16D385 

25142411201405551605 ULTIPLE NE 

ULP S 






009 

5173D22E008C3C3 

24271722135502141703 TWORK BLOC 

QSR.P < 






010 

2D3B5540C24E16D 

13235525201411160555 KS UPLINE 

2S5T $AM 






Oil 

500000000000000 

24000000000000000000 T 

P 






14.15.41 

.736 NETPUT (016735) HA =013520 TA =002403 



MSG 

NO. 

000045 

ABT =02 

ADR =0001 ABN 

=000003 ACT =04 STATUS = 00000000 TLC = 

0020 





001 

BCE15852014E512 

57160530245505162422 .NEXT ENTR 

<AXRQNQ 






002 

679000000000000 

31710000000000000000 Y? 

8Y 






14.16.08 

.202 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX 

=0063 

MSG 

NO. 

000046 

ABT =03 

ADR =0000 ABN 

=000000 ACT =01 STATUS = 00000000 TLC = 

0001 





001 

830200001000080 

40601000000100000200 FCACK 







14.16.08 

.202 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX 

=0063 

MSG 

NO. 

000047 

ABT =03 

ADR =0000 ABN 

=000000 ACT =01 STATUS = 00000000 TLC = 

0001 





001 

830200001OOOOCO 

40601000000100000300 FCACK 







14.16.08 

.205 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLMAX 

=0063 

MSG 

NO. 

000048 

ABT =01 

ADR =0001 ABN 

=000000 ACT =04 STATUS = 00000000 TLC = 

0100 





001 

3ED508160385517 

17552410055516052427 0 THE NETW 

>U S Q 






002 

3D22ED05040C243 

17221355012020141103 ORK APPLIC 

SR.PPBBC 






003 

05424F3A04123C7 

01241117165520221707 ATION PROG 

BO T < 






004 

48136FB6D508149 

22011557555524100511 RAM. THEI 

T 6CHP I 






005 

39414E52D253B54 

16240516245511235524 NTENT IS T 

9ANRRS5 






006 

3ED4C516D5C8054 

17552305055527100124 0 SEE WHAT 

CMLQM T 






007 

B54205B5048F1D2 

55241005552022170722 THE PROGR 

5B 5 






008 

04DE13B51545545 

01157023552125052505 AM'S QUEUE 

MA;QTUE 






009 

98804E10C24E1ED 

46100116041411160755 -HANDLING 

N BN 






010 

0CF105B5724C32D 

03170405552711141455 CODE WILL 

PO CW$C- 






14.16.08 

208 NETPUT (016735) HA =013520 TA =002403 



MSG 

NO. 

000049 

ABT =01 

ADR =0001 ABN 

=000004 ACT =04 STATUS = 00000000 TLC = 

0110 





001 

BCFB54205B4E154 

57175524100555160524 .0 THE NET 

<CT CN 






002 

5CF48BB41410309 

27172213550120201411 WORK APPLI 

EOH;AA 






003 

0C15093CEB5048F 

03012411171655202217 CATION PRO 

<KPH 






004 

1D204DBEDB54205 

07220115575555241005 GRAM. THE 

QR CM5B 







Figure 8-21. Debug Log File Listing for ECH0-RMV2 (Sheet 7 of 9) 
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RHV2 LOG FILE OUTPUT 
DATE RECORDED - 85/08/27 


005 24E505394B494ED 
006 50FB53145B57201 
007 52D5081604123C7 
008 4813784ED455155 
009 166201384309387 
010 B433C416D5C930C 
011 000000000000000 


11162405162455112355 
24175523050555271001 
24552410055520221707 
22011570235521250525 
05461001160414111607 
55031704055527111414 
00000000000000000000 


INTENT IS $E 9KIN 
TO SEE WHA U 51E5R 
T THE PROG RU T < 
RAM'S QUEU T 7 HEQU 
E-HANDLING B 8C 8 
CODE WILL CC<AM 


85/08/27 
PAGE 00008 


14.16.08.218 NETPUT (016735) HA =013520 TA =002403 

ABT =02 ADR =0001 ABN =000005 ACT =04 STATUS = 00000000 TLC = 0020 

001 BCE15852D14E512 57160530245505162422 .NEXT ENTR <AXRQNQ 

002 679000000000000 31710000000000000000 Y? &Y 

14.16.08.222 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLMAX =0063 

ABT =02 ADR =0001 ABN =000000 ACT =04 STATUS = 00000000 TLC = 0019 

001 10FB493AD508253 04175511165524101123 DO IN THIS Q U % 

002 24E40404E0C5BC0 11162324011603055700 INSTANCE. 2NHaN Ca 

14.16.13.980 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000100 40601000000100000400 FCACK 

14.16.13.980 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000140 40601000000100000500 FCACK 

14.16.13.983 NETPUT (016735) HA =013520 TA =002403 

ABT =01 ADR =0001 ABN =000006 ACT =04 STATUS = 00000000 TLC = 0030 

001 BC43ED24EB54209 57041755111655241011 .DO IN THI <CH$KT 
002 4C939350138316F 23111623240116030557 SINSTANCE. 195 810 
003 000000000000000 00000000000000000000 


MSG NO. 000050 


MSG NO. 000051 


MSG NO. 000052 


MSG NO. 000053 


MSG NO. 000054 


14.16.13.986 NETPUT (016735) HA =013520 TA =002403 

ABT =02 ADR =0001 ABN =000007 ACT =04 STATUS = 00000000 TLC = 0020 

001 BCE15852014E512 57160530245505162422 .NEXT ENTR <AXRQNQ 
002 679000000000000 31710000000000000000 Y? 8Y 


MSG NO. 000055 


14.16.23.135 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 

001 830200001000180 40601000000100000600 FCACK 


MSG NO. 000056 
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RMV2 LOG FILE OUTPUT 
DATE RECORDED - 85/08/27 


85/08/27 
PAGE 00009 


14.16.23.136 NETGET (016407) ACN =0000 HA =013520 TA =013561 TLMAX =0063 MSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001 


001 8302000010001 CO 40601000000100000700 FCACK 


14.16.35.192 NETGETL (016423) ALN =0001 HA =013520 TA =002304 TLHAX =0063 MSG NO. 

ABT =02 ADR =0001 ABN =000000 ACT =04 STATUS = 00000000 TLC = 0008 


001 4C855410F5CE000 23102524041727160000 SHUTDOWN L T UN 


14.16.35.237 NETPUT (016735) HA =013520 TA =002403 MSG NO. 

ABT =02 ADR =0001 ABN =000008 ACT =04 STATUS = 00000000 TLC = 0020 

001 BC2645B463D2156 57023105550617220526 .BYE FOREV <8E4CR 
002 152D80000000000 05226600000000000000 ER! ARX 


14.16.35.240 NETPUT (016735) HA =013520 TA =002403 MSG NO. 

ABT =02 ADR =0001 ABN =000009 ACT =04 STATUS = 00000000 TLC = 0020 

001 BD32155043D73AD 57231025240417271655 .SHUTDOWN =2 PCW 

002 0CF349387000000 03171511160700000000 COMING P04 


14.16.35.240 NETPUT (016735) HA =013520 TA =013561 MSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0001. 

001 C00000001000000 60000000000100000000 LSTOFF a 


14.16.35.240 NETPUTF (016753) HA =013520 NA =001 TAA =013660 MSG NO. 

ABT =03 ADR =0000 ABN =000000 ACT =01 STATUS = 00000000 TLC = 0002 


FRAGMENT 001 SIZE =0002 ADDRESS = 013561 

001 630600001000000 30603000000100000000 X#X A C 

002 2411ADB6DB40000 11010655555555000000 lAF A CM4 


14.16.38.071 NETOFF (013560) DATE =85/08/27 


MSG NO. 


Figure 8-21. Debug Log File Listing for ECH0-RHV2 (Sheet 9 of 9) 


000057 


000058 


000059 


000060 


000061 


000062 


000063 
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NAM STATISTICS GATHERING 

STARTED 

NETON DATE 85/08/27. 

TIME 

14.09.14. 

NAM STATISTICS GATHERING 

TERMINATED 

NETOFF DATE 85/08/27. 

TIME 

14.16.38. 

CPU TIME USED: 

0.140 

SEC 

NUMBER OF PROCEDURE CALLS 


NET6ET 

54 


NETGETL 

31 


NETPUT 

27 


NETPUTF 

2 


NETWAIT 

22 


NUMBER OF WORKLIST TRANSFER ATTEMPTS 

SUCCESSFUL 

57 


NUMBER OF INPUT/OUTPUT BLOCKS TRANSFERRED 

INPUT ABT=0 

44 


INPUT ABT=1 

2 


INPUT ABT=2 

5 


INPUT ABT=3 

25 


OUTPUT ABT=1 

5 


OUTPUT ABT=2 

12 


OUTPUT ABT=3 

12 


NUMBER OF ERRORS 




Figure 8-22. 


Statistics File Listing for ECH0-RMV2 
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THIS IS RMV2 USING 9TRM. ENTER SOMETHING. 

The next character is a user-break-2 character. 

THE NEXT CHARACTER IS A USER-BREAK-2 CHARACTER. 

NEXT ENTRY? 

© 

NO ACTION TAKEN. NEXT ENTRY? 

The next character is a user-break-1 character. 

THE NEXT CHARACTER IS A USER-BREAK-1 CHARACTER. 

NEXT ENTRY? 

® 

NO ACTION TAKEN. NEXT ENTRY? 
end 

GOODBYE FOR NOW.. 

RMV2 CONNECT TIME 00.01.10 

JSN: AAJO, NAMIAF 
/bye,rmv2 

UN=xxxxxx LOG OFF 14.13.00. 

JSN=AAJO SRU-S= 1.012 

CHARACTERS= 0.113KCHS 
lAF CONNECT TIME 00.00.42. 

THIS IS RMV2 USING QTRM. ENTER SOMETHING. 

This is a typeahead test, entering as much text as possible to cause 
multiple network blocks upline to the network application program. The 
intent is to see what the program's queue-handling code will do in this 
instance. 

THIS IS A TYPEAHEAD TEST, ENTERING AS MUCH TEXT AS POSSIBLE TO CAUSE MULTIPLE NET 
WORK BLOCKS UPLINE T 
NEXT ENTRY? 

0 THE NETWORK APPLICATION PROGRAM. THEINTENT IS TO SEE WHAT THE PROGRAM'S QUEUE 
-HANDLING CODE WILL 
DO IN THISINSTANCE. 

NEXT ENTRY? 
shutdown 
BYE FOREVER! 

SHUTDOWN COMING 

RMV2 CONNECT TIME 00.03.34. 

JSN: AAJS, NAMIAF 


Figure 8-23. ECHO-RMV2 Sample Dialog 
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CHARACTER DATA INPUT, OUTPUT, AND 
CENTRAL MEMORY REPRESENTATION 


A 


This appendix describes the code and character sets 
used by the operating system local batch device 
driver programs, magnetic tape driver programs, and 
network terminal communication products. This 
appendix does not describe how other products 
associate certain graphic or control characters 
with specific binary code values for collating or 
syntax processing purposes. The main text of this 
manual describes such associations that are rele¬ 
vant to the reader. 


CHARACTER SETS AND CODE 
SETS 

A character set differs from a code set. A char¬ 
acter set is a set of graphic and/or control char¬ 
acter symbols. A code set is a numbering system 
used to represent each character within a character 
set. Characters exist outside the computer system 
and communication network; codes are received, 
stored, retrieved, and transmitted within the 
computer system and network. 

When this manual refers to the ASCII 128-character 
set or the 7-bit ASCII code set, it is referring to 
the character set and code set defined as the 
American National Standard Code for Information 
Interchange (ASCII, ANSI Standard X3.4-1977). 
References in this manual to an ASCII character set 
or an ASCII code set do not necessarily apply to 
the 128-character, 7-bit ASCII code set. 


GRAPHIC AND CONTROL 
CHARACTERS 

A graphic character can be displayed or printed. 
Examples of graphic characters are the characters A 
through Z, a blank, and the digits 0 through 9. A 
control character is not a graphic character; a 
control character initiates, modifies, or stops a 
control operation. An example of a control char¬ 
acter is the backspace character, which moves the 
terminal carriage or cursor back one space. Al¬ 
though a control character is not a graphic char¬ 
acter, some terminals use a graphic representation 
for control characters. 

CODED AND BINARY 
CHARACTER DATA 

Character codes can be interpreted as coded char¬ 
acter data or as binary character data. Coded 
character data is converted by default from one 
code set representation to another as it enters or 
leaves the computer system; for example, data 
received from a terminal or sent to a magnetic tape 
unit is converted. Binary character data is not 
converted as it enters or leaves the system. 
Character codes are not converted when moved within 
the system; for example, data transferred to or 
from mass storage is not converted. 


The distinction between coded character data and 
binary character data is important when reading or 
punching cards and when reading or writing magnetic 
tape. Only coded character data can be properly 
reproduced as characters on a line printer. Only 
binary character data can properly represent 
characters on a punched card when the data cannot 
be stored as display code. 

The distinction between binary character data and 
characters represented by binary data (such as 
peripheral equipment instruction codes) is also 
important. Only binary noncharacter data can 
properly reproduce characters on a plotter. 


CHARACTER SET TABLES 

The character set tables in this appendix are 
designed so that the user can find the character 
represented by a code (such as in a dump) or find 
the code that represents a character. To find the 
character represented by a code, the user looks up 
the code in the column listing the appropriate code 
set and then finds the character on that line in 
the column listing the appropriate character set. 
To find the code that represents a character, the 
user looks up the character and then finds the code 
on the same line in the appropriate column. 


NETWORK OPERATING 
SYSTEM 

NOS supports the following character sets: 

CDC graphic 64-character set 
CDC graphic 63-character set 
ASCII graphic 64-character set 
ASCII graphic 63-character set 
ASCII graphic .95-character set 
ASCII 128-character set 

Each installation must select either a 64-character 
set or a 63-character set. The differences between 
the codes of a 63-character set and the codes of a 
64-character set are described under Character Set 
Anomalies. Any reference in this appendix to a 
64-character set implies either a 63- or 64- 
character set unless otherwise stated. 

NOS supports the following code sets to represent 
its character sets in central memory: 

6-bit display code 
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12-blt ASCII code 
6/12-bit display code 


A-1 



The 6-bit display code is a set of octal codes from 
00 to 77, inclusive. 

The 12-blt ASCII code is the ASCII 7-bit code 
right-Justif led in a 12-blt byte. The bits are 
numbered from the right starting with 0; bits 0 
through 6 contain the ASCII code, bits 7 through 10 
contain zeros, and bit 11 distinguishes the 12-bit 
ASCII 0000 code from the 12-bit 0000 end-of-line 
byte. The octal values for the 12-bit codes are 
0001 through 0177 and 4000. 

The 6/12-bit display code is a combination of 6-blt 
codes and 12-bit codes. The octal values for the 
6-bit codes are 00 through 77, excluding 74 and 
76. (The interpretation of the .00 and 63 codes is 
described under Character Set Anomalies in this 

appendix.) The octal 12-blt codes begin with 

either 74 or 76 and are followed by a 6-blt code. 
Thus, 74 and 76 are escape codes and are never used 
as 6-bit codes within the 6/12-bit display code 
set. The octal values of the 12-bit codes are: 

7401, 7402, 7404, 7407, and 7601 through 7677. The 

other 12-bit codes, 74xx and 7600, are undefined. 


CHARACTER SET ANOMALIES 

The operating system input/output software and some 
products interpret two codes differently when the 
Installation selects a 63-character set rather than 
a 64-character set. If a site uses a 63-character 
set: the colon (:) graphic character is always 
represented by a 6-bit display code value of 63 
octal; display code 00 is undefined (it has no 
associated graphic or punched card code); the per¬ 
cent (%) graphic does not exist, and translations 
produce a space (55 octal). 

However, if the site uses a 64-character set, out¬ 
put of an octal 7404 6/12-bit display code or a 
6-blt display code value, of 00 produces a colon. 
In ASCII mode, a colon can be input only as a 7404 
6/12-bit display code. Undefined 6/12-blt display 
codes in output files produce unpredictable results 
and should be avoided. 

Two consecutive 6-bit display code values of 00 can 
be confused with the 12-blt 0000 end-of-line byte 
and should be avoided. 

Translation of 7-bit or 12-blt ASCII to 6-blt 
display code causes character folding from the 
128-character ASCII set to the 63- or 64-character 
ASCII subset, with the special character substitu¬ 
tions shown in figure A-1. 


INTERACTIVE TERMINAL USERS 

NOS supports display consoles and teletypewriters 
that use code sets other than 7-bit ASCII codes for 
communication or use graphics other than those 
defined in an ASCII character set. Data exchanged 
with such terminals is translated as described 
under Terminal Transmission Modes in this appen¬ 
dix. The following description applies only to 
terminals that use 7-bit ASCII codes and the ASCII 
character set. 


ASCII Data Exchange Modes 

Table A-1 shows the character sets and code sets 
available to an Interactive Facility (lAF) user. 
Table A-2 shows the octal and hexadecimal 7-bit 
ASCII code for each ASCII character, and can be 
used to convert codes from octal to hexadecimal. 
(Certain Terminal Interface Program commands re¬ 
quire hexadecimal specification of a 7-bit ASCII 
code.) 

lAF supports both normalized mode and transparent 
mode transmissions through the network. These 
transmission modes are described under Terminal 
Transmission Modes in this appendix. Refer to the 
NOS Version 2 Reference Set, Volume 3 System Com¬ 
mands, for additional information. 

lAF treats normalized mode transmissions as coded 
character data; lAF converts these transmissions to 
or from either 6-bit or 6/12-bit display code. 

lAF treats transparent mode transmissions as binary 
character data. Transparent mode input or output 
uses 12-bit bytes, with bit 11. always set to 1; for 
ASCII terminals, transparent mode input and output 
occurs in the 12-bit ASCII code shown in table A-1, 
but the leftmost digit is 4 Instead of 0. 

When the NORMAL command is in effect, LAF assumes 
that the ASCII graphic 64-character set is used and 
translates all input and output to or from display 
code. When the ASCII command is in effect, lAF 
assumes that the ASCII 128-character set is used 
and translates all input and output to or from 
6/12-bit display code. 

The lAF user can convert a 6/12-bit display code 
file to a 12-blt ASCII code file using the NOS 
FCOPY control statement. The resulting 12-blt 
ASCII file can be routed to a line printer but the 
file cannot be output through lAF. 


63- or 64-Character Subset 


12-Bit ASCII (Octal) 


6-Bit Display Code (Octal) 

12-Bit ASCII (Octal) 

0140 ( ■) 


74 (a) 


0100 (a) 

0173 ({) 


61 (D 


0133 (C) 

0174 (|) 

Input 

75 (\) 

Output^ 

0134 (\) 

0175 (» 


62 (3) 


0135 (3) 

0176 {■) 


76 (•^) 


0136 (^) 


Figure A-1. ASCII Character Folding 
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Terminal Transmission Modes 

Coded character data can be exchanged with a con¬ 
versational terminal In two transmission modes. 
These two modes, normalized mode and transparent 
mode, correspond to the types of character code 
editing and translation performed by the network 
software during Input and output operations. 

The terminal operator can change the input trans¬ 
mission mode using a terminal definition command 
(sometimes called a Terminal Interface Program 
command). The application program providing the 
terminal facility service can change the input or 
output transmission mode. 

Normalized Mode Transmissions 

Normalized mode is the initial and default mode 
used for both input and output transmissions. The 
network software translates normalized mode data to 
or from the transmission code used by the terminal 
into or from the 7-bit ASCII code shown in table 
A-2. (Tables A-1 and A-3 through A-7 are provided 
for use while coding an application program to run 
under the operating system; they do not describe 
character transmissions through the network.) 
Translation of a specific terminal transmission 
code to or from a specific 7-bit ASCII code depends 
on the terminal class in which the network software 
places the terminal. 

The following paragraphs summarize the general case 
for normalized mode data code translations. This 
generalized description uses table A-2. 

The reader can extend this generalized description 
by using the other tables to determine character 
set mapping for functions initiated from a terminal. 
For example, the description under Terminal Output 
Character Sets can be used to predict whether a 
lowercase ASCII character stored in 6/12-blt dis¬ 
play code can appear on an EBCDIC or external BCD 
terminal; if an ASCII character passes through the 
network represented in 7-blt ASCII as character 
mode data, it probably can be represented on an 
EBCDIC terminal, but it is always transformed to an 
uppercase character on a mode 4A ASCII terminal. 

Table A-2 contains the ASCII 128-character set 
supported by the network software. The ASCII 
96-character subset in the rightmost six columns 
minus the deletion character (DEL) comprises the 
graphic 95-character subset; the DEL is not a 
graphic character, although some terminals graphi¬ 
cally represent it. The graphic 64-character 
subset comprises the middle four columns. Only the 
characters in this 64-character subset have 6-blt 
display code equivalents. 

Terminals that support an ASCII graphic 64-character 
subset actually use a subset of up to 96 charac¬ 
ters, consisting of the graphic 64-character subset 
and the control characters of columns 1 and 2; 
often, the DEL character in column 7 is Included. 
Terminals that support an ASCII graphic 95-character 
or 96-character subset actually might use all 128 
characters. 

The hexadecimal value of the 7-blt code for each 
character in table A-2 consists of the character's 
column number in the table, followed by its row 
number. For example, N is in row E of column 4, so 


its hexadecimal value is 4E. The octal value for 
the code when it is right-justif led in an 8-blt 
byte appears beneath the character graphic or 
mnemonic. The binary value of the code consists of 
the bit values shown, placed in the order given by 
the subscripts for the letter b; for example, N is 
1001110. 

Tables A-8 through A-19 show the normalized mode 
translations performed for each terminal class. 
The parity shown in the terminal transmission codes 
is the parity used as a default for the terminal 
class. The parity setting actually used by a 
terminal can be identified to the network software 
through a TIP command. 

Tables A-8 through A-19 contain the graphic and 
control characters associated with the transmission 
codes used by the terminal because of the terminal 
class and code set in use. The network ASCII 
graphic and control characters shown are those of 
the standard ASCII character set associated with 
the ASCII transmission codes of table A-2. 

Terminal Output Character Subsets — Although the 
network supports the ASCII 128—character set, some 
terminals restrict output to a smaller character 
set. This restriction is supported by replacing 
the control characters in columns 0 and 1 of table 
A-2 with blanks to produce the ASCII graphic 
95-character subset, and replacing the characters 
in columns 6 and 7 with the corresponding char¬ 
acters from columns 4 and 5, respectively, to 
produce the ASCII graphic 64-character subset. 

Terminal Input Character Subsets and Supersets — 
Although the network supports the ASCII 128- 
character set, some terminals restrict input to a 
smaller character set or permit input of a larger 
character set. A character input from a device 
using a character set other than ASCII is converted 
to an equivalent ASCII character; terminal char¬ 
acters without ASCII character equivalents are 
represented by the ASCII code for a space. 

Site-written terminal-servicing facility programs 
can also cause input or output character replace¬ 
ment, conversion, or deletion by exchanging data 
with the network in 6-blt display code. 

Input Restrictions — The network software automat¬ 
ically deletes codes associated with terminal 
communication protocols or terminal hardware func¬ 
tions. These codes usually represent the cancel, 
backspace, linefeed, carriage return, and deletion 
characters. If paper ..tape support is requested, 
the device control 3 code also is deleted. Some of 
these code deletions can be suppressed by using the 
full-ASCII and special editing options (refer to 
the FA and SE terminal definition parameters in the 
NOS Version 2 Reference Set, Volume 3, System 
Commands). 

Output Restrictions — All codes sent by an appli¬ 
cation program are transmitted to the terminal. 
However, the i2-bit ASCII code 0037 (octal), the 
6/12-bit display code 7677 (octal), and the 7-bit 
ASCII code IF (hexadecimal) should be avoided in 
character mode output. The network software inter¬ 
prets the unit separator' character represented by 
these codes as an end-of-line indicator. The 
processing of application program-supplied unit 
separators causes incorrect formatting of output 
and can cause loss of other output characters. 
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Input Parity Processing — The network software 
does not preserve the parity of the terminal trans¬ 
mission code In the corresponding ASCII code. An 
ASCII code received by the terminal-servicing 
facility program always contains zero as Its eighth 
bit. 

Output Parity Processing — The network software 
provides the parity bit setting appropriate for the 
terminal being serviced, even when the software Is 
translating from ASCII character codes with zero 
parity bit settings. 


Transparent Mode Transmissions 

Transparent mode Is selected separately for input 
and output transmissions. 

During transparent mode Input, the parity bit Is 
stripped from each terminal transmission code 
(unless the N or I parity option has been selected 
by a terminal definition command), and the 
transmission code is placed In an 8-blt byte 
without translation to 7-blt ASCII code. Line 
transmission protocol characters are deleted from 
mode 4 terminal Input. When the 8-bit bytes arrive 
in the host computer, a terminal servicing facility 
program can rlght-justify the bytes within a 12-bit 
byte. 


During transparent mode output, processing similar 
to that performed for input occurs. When the host 
computer transmits 12-blt bytes, the leftmost 4 
bits (bits 11 through 8) are discarded. The code 
In each 8-blt byte received by the network software 
Is not translated. The parity bit appropriate for 
the terminal class is altered as indicated by the 
parity option In effect for the terminal. The 
codes are then transmitted to the terminal In bytes 
of a length appropriate for the terminal class. 
Line transmission protocol characters are Inserted 
Into mode 4 terminal output. 


LOCAL BATCH USERS 

Table A-3 lists the CDC graphic 64-character set, 
the ASCII graphic 64-character set, and the ASCII 
graphic 95-character set available on local batch 
devices. This table also lists the code sets and 
card keypunch codes (026 and 029) that represent 
the characters. 

The 64-character sets use 6-bit display code as 
their code set; the 95-character set uses 12-blt 
ASCII code. The 95-character set Is composed of 
all the characters in the ASCII 128-character set 
that can be printed at a line printer (refer to 
Line Printer Output). Only 12—bit ASCII code files 
can be printed using the graphic ASCII 95-character 
set. The 95-character set is represented by the 
octal 12-bit ASCII codes 0040 through 0176. An 
octal 12-blt ASCII code outside of the range 0040 
through 0176 represents an unprintable character. 

To print a 6/12-bit display code file, the user 
must convert the file to 12-blt ASCII code. The 
NOS FCOPY control statement Is used for this con¬ 
version. 


Line Printer Output 

The printer train used on the line printer to which 
a file is sent determines which batch character set 
is printed. The following CDC print trains match 
the batch character sets in table A-3: 



Print 

Low Cost System 

Character Set 

Train 

Print Band 

CDC graphic 
64-character set 

596-1 

— 

ASCII graphic 
64-character set 

596-5 

530-1 

ASCII graphic 
95-character set 

596-6 

530-2 


The characters of the default 596-1 print train are 
listed in the table A-3 column labeled CDC Graphic 
(64-Character Set); the 596-5 print train charac¬ 
ters are listed In the table A-3 column labeled 
ASCII Graphic (64-Character Set); and the 596-6 
print train characters are listed in the table A-3 
column labeled ASCII Graphic (95-Character Set). 

If an unprintable character exists in a line, NOS 
marks the condition by printing the number sign (#) 
in the first printable column of the line. A space 
replaces the unprintable character within the line. 

When a transmission error occurs during the print¬ 
ing of a line, NOS makes up to five attempts to 
reprint the line. The CDC graphic print train 
prints a concatenation symbol ( r* ) in the first 
column of the repeated line following a line con¬ 
taining errors. The ASCII print trains print an 
underline ( _ ) instead of the concatenation symbol. 

After the fifth attempt, the setting of sense 
switch one for the batch input and output control 
point determines further processing. NOS either 
rewinds the file and returns it to the print queue, 
or ignores the transmission errors. 


Punched Card Input and Output 

A character represented by multiple punches in a 
single column has its punch pattern identified by 
numbers and hyphens. For example, the punches 
representing an exclamation point are identified as 
11-0; this notation means both rows 11 and 0 are 
punched in the same column. 

A multiple punch pattern that represents something 
other than a character is identified by numbers and 
slashes. For example, the punches representing the 
end of an input file are identified as 6/7/8/9; 
this notation means rows 6 through 9 are punched in 
the same column. 

Coded character data is exchanged with card readers 
or card punches according to the translations shown 
in table A-3. As indicated in the table, other 
card keypunch codes are available for input of the 
ASCII and CDC characters [ and ]. NOS cannot read 
or punch the 95-character set as coded character 
data. 

Each site chooses either 026 or 029 as its default 
keypunch code. NOS begins reading an input deck in 
the default code (regardless of the character set 
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in use). The user can specify the alternate key¬ 
punch code by punching a 26 or 29 in columns 79 and 
80 of any job card, 6/7/9 card, or 7/8/9 card. The 
specified translation continues throughout the job 
unless the alternate keypunch code translation is 
specified on a subsequent 6/7/9 or 7/8/9 card. 

A 5/7/9 card with a punch in column 1 changes 
keypunch code translation if the card is read 
immediately before or after a 7/8/9 card. A space 
(no punch) in column 2 indicates 026 translation 
mode; a 9 punch in column 2 indicates 029 transla¬ 
tion mode. The specified translation remains in 
effect until a similar 5/7/9 card or a 7/8/9 card 
is encountered, or the job ends. 

The 5/7/9 card also allows literal input when 
4/5/6/7/8/9 is punched in column 2. Literal input 
can be used to read 80-column binary character data 
within a punched card deck of coded character data. 

Literal cards are stored with each column repre¬ 
sented in a 12-blt byte (a row 12 punch is repre¬ 
sented by a 1 in bit 11, row 11 by a 1 in bit 10, 
row 0 by a 1 in bit 9, and rows 1 through 9 by I's 
in bits 8 through 0 of the byte), using 16 central 
memory words per card. Literal input cards are 
read until another 5/7/9 card with 4/5/6/7/8/9 
punched in column 2 is read. The next card can 
specify a new conversion mode. 

If the card following the 5/7/9, 6/7/9, or 7/8/9 
card has a 7 and a 9 punched in column 1, the sec¬ 
tion of the job deck following it contains system 
binary cards (as described in the NOS Version 2 
Reference Set, Volume 3, System Commands). 


REMOTE BATCH USERS 

Remote batch console input and output is restricted 
to character mode transmission. Character mode is 
described under Terminal Transmission Modes in this 
appendix. 

The abilities to select alternate keypunch code 
translations, to read binary cards, to output 
plotter files, and to print lowercase characters 
depend upon the remote terminal equipment. Remote 
batch terminal support under NOS is described in 
the Remote Batch Facility (RBF) reference manual. 


MAGNETIC TAPE USERS 

The character and code sets used for reading and 
writing magnetic tapes depend on whether coded or 
binary data is read or written and on whether the 
tape is 7-track or 9-track. 


Coded Data Exchanges 

Coded character data to be copied from mass storage 
to magnetic tape is assumed to be stored in a 
63- or 64-character 6-bit display code. The oper¬ 
ating system magnetic tape driver program converts 
the data to 6-bit external BCD code when writing a 
coded 7-track tape and to 7-bit ASCII or 8-bit 
EBCDIC code (as specified on the tape assignment 
statement) when writing a coded 9-track tape. 


Coded character data copied to mass storage from 
magnetic tape is stored in a 63- or 64-character 
6-bit display code. The operating system magnetic 
tape driver program converts the data from 6-bit 
external BCD code when reading a coded 7-track tape 
and from 7-bit ASCII or 8-biL EBCDIC code (as 
specified on the tape assignment statement) when 
reading a coded 9-track tape. 

To read and write lowercase character 7-bit ASCII 
or 8-bit EBCDIC codes or to read and write control 
codes, the user must assign a 7-track or 9-track 
tape in binary mode. 


Seven-Track Tape Input and Output 

Table A-4 shows the code and character set conver¬ 
sions between 6-bit external BCD and 6-bit display 
code for 7-track tapes. Because only 63 characters 
can be represented in 7-track even parity, one of 
the 64 display codes is lost in conversion to and 
from external BCD code. 

Figure A-2 shows the differences in 7-track tape 
conversion that depend on whether the system uses 
the 63-character or 64-character set. The ASCII 
character for the specified character code is shown 
in parentheses. The output arrows show how the 
6-bit display code changes when it is written on 
tape in external BCD. The input arrows show how 
the external BCD code changes when the tape is read 
and converted to display code. 



63-Character Set 


Display Code 

External BCD 

Display Code 

00 

16 (%) 

00 

33 (0) 

Output 12 (0) Input 

33 (0) 

63 (:) 

-► 12 (0) - 

33 (0) 


64-Character Set 


Display Code 

External BCD 

Display Code 

00 (;) 

12 (0) 

33 (0) 

33 (0) 

Output 12 (0) Input 

33 (0) 

63 (%) 

-► 16 (%) - 

► 63 (%) 


Figure A-2. Magnetic Tape Code Conversions 


Nine-Track Tape Input and Output 

Table A-5 lists the conversions between the 7-blt 
ASCII code used on the tape and the 6-bit display 
code used within the system. Table A-6 lists the 
conversions between the 8-bit EBCDIC code used on 
the tape and the 6-bit display code used within the 
system. 

When an ASCII or EBCDIC code representing a lower¬ 
case character is read from a 9-Lrack magnetic 
tape, it is converted to its uppercase character 
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6-bit display code equivalent. Any EBCDIC code not 
listed in table A-6 is converted to display code 55 
(octal) and becomes a space. Any code between 80 
(hexadecimal) and FF (hexadecimal) read from an 
ASCII tape is converted to display code 00. 

Binary Character Data Exchanges 

Binary character data exchanged between central 
memory files and magnetic tape is transferred as a 
string of bytes without conversion of the byte 
contents. The grouping of the bytes and the number 
of bits in each byte depend on whether 7-track or 
9-track tape is being used. 


Seven-Trac k Tape Input and Output 

Each binary data character code written to or read 
from 7-track magnetic tape is assumed to be stored 
in a 6-blt byte, such as the system uses for 63- or 
64-character 6-blt display code. Seven-bit ASCII 
and 8-bit EBCDIC codes can only be read from or 
written to 7-track magnetic tape as binary charac¬ 
ter data if each code is stored within a 12-blt 
byte as if it were two character codes. 


Nine-Track Tape Input and Output 

Each binary data character code exchanged between 
central memory files and 9-track magnetic tape is 
assumed to be stored in an 8-bit or 12-bit byte. 


During such binary data transfers, the 6/12-blt 
display codes and 12-blt ASCII codes shown in table 
A-1, the 7-bit ASCII codes shown in table A—2, or 
or the 8-blt hexadecimal EBCDIC codes shown in 
table A-7 can be read or written. The 7-bit ASCII 
codes and 8-bit EBCDIC codes can be exchanged 

either in an unformatted form or right-justified 
within a zero-filled 12-blt byte of memory. 

When 9-track tape is written, every pair of 12-bit 
memory bytes becomes three 8-blt tape bytes; when 
9-track tape is read, every three 8-bit tape bytes 
become a pair of 12-blt memory bytes. Because of 
the 12-bit byte pairs, codes not packed into 12-bit 
bytes are exchanged in their unpacked form, while 
codes packed in 12-bit bytes are exchanged in 

packed form. 

When an odd number of central memory words is read 
or written, the lower four bits of the last 8-bit 
byte (bits 0 through 3 of the last word) are not 
used. For example, three central memory words are 
written on tape as 22 8-bit bytes (7.5 pairs of 
12-bit bytes) and the remaining four bits are 
ignored. 

CODE CONVERSION AIDS 

Table A-7 contains the octal values of each 8-bit 
EBCDIC code right-justified in a 12-bit byte with 
zero fill. This 12-bit EBCDIC code can be produced 
or read using the FORM and 8-Bit Subroutines 
utilities. 
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TABLE A-l. INTERACTIVE TERMINAL CHARACTER SETS 


Character Sets 

Code Sets 



Octal 

Octal 

Octal 

ASCII Graphic 

ASCTC Character 

6“Bit 

6/12-Btt 

12-Blt 

(64-CharacCer Set) 

(128-Character Set) 

Display 

Display 

ASCII 



Code 

Codet 

1 

Code 

: colontt 


00 tt 



A 

A 

01 

01 

0101 

B 

B 

02 

02 

0102 

c 

C 

03 

03 

0103 

D 

D 

04 

04 

0104 

E 

E 

05 

05 

0105 

F 

F 

06 

06 

0106 

G 

G 

07 

07 

0107 

H 

H 

10 

10 

0110 

I 

[ 

11 

11 

0111 

J 

j 

12 

12 

0112 

K 

K 

J3 

13 

0113 

L 

L 

14 

14 

0114 

M 

M 

15 

15 

0115 

N 

N 

16 

16 

0116 

0 

0 

17 

17 

0117 

P 

P 

20 

20 

0120 

Q 

Q 

21 

21 

0121 

R 

R 

22 

22 

0122 

S 

S 

23 

23 

0123 

T 

T 

24 

24 

0124 

U 

U 

25 

25 

0125 

V 

V 

26 

26 

0126 

w 

w 

27 

27 

0127 

X 

X 

30 

30 

0130 

Y 

Y 

31 

31 

0131 

z 

Z 

32 

32 

0132 

0 

0 

33 

33 

0060 

1 

i 

34 

34 

0061 

2 

2 

35 

35 

0062 

3 

3 

36 

36 

0063 

4 

4 

37 

37 

0064 

5 

5 

40 

40 

0065 

6 

6 

41 

41 

0066 

7 

7 

42 

42 

0067 

8 

8 

43 

43 

0070 

9 

9 

44 

44 

0071 

+ plus 

+ plus 

45 

45 

0053 

- hyphen (minus) 

- hyphen (minus) 

46 

46 

0055 

* asterisk 

* asterisk 

47 

47 

0052 

/ slant 

/ slant 

50 

50 

0057 

( opening parenthesis 

( opening parenthesis 

51 

51 

0050 

) closing parenthesis 

) closing parenthesis 

52 

52 

0051 

$ dollar sign 

$ dolJar sign 

53 

53 

0044 

= equals 

= equals 

54 

54 

0075 

space 

space 

55 

55 

0040 

, comma 

, comma 

56 

56 

0054 

. period 

. period 

57 

57 

0056 

# number sign 

# number sign 

60 

60 

0043 

[ Opening bracket 

[ opening bracket 

61 

61 

0133 

] closing bracket 

] closing bracket 

62. . 


0135 

X percent signtt 

% percent signTt 

63tt 

63tt 

0045 

" quotation mark 

" quotation mark 

64 

64 

0042 

underline 

underlIne 

65 

65 

0137 

! exclamation point 

! exclamation point 

66 

66 

0041 

& ampersand 

& ampersand 

67 

67 

0046 

apostrophe 

apostrophe 

70 

70 

0047 

? question mark 

? question mark 

71 

71 

0077 
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TABLE A-1. INTERACTIVE TERMINAL CHARACTER SETS (Contd) 


Character Sets 

Code Sets 



Octal 

Octal 

Octal 

ASCII Graphic 

ASCII Character 

6-Bit 

6/12-Bit 

12-BLt 

(64-Character Set) 

(128-Character Set) 

Display 

Display 

ASCII 



Code 

Codet 

Code 

< less than 

< less' than 

72 

72 

0074 

> greater than 

> greater than 


73 

0076 

@ commmercial at 

@ commercial at 

74tt 

7401tt 

0100 

\ reverse slant 

\ reverse slant 

75 

75 

0134 

/N circumf lex 


76 



; semicolon 

; semicolon 

77 

77 

0073 


^ circumf3ex 

76tt 

7402 

0136 


: colontt 

TAtt 

7404tt 

0072 


' grave accent 


7407 

0140 


a 


7601 

0141 


b 


7602 

0142 


c 


7603 

0143 


d 


7604 

0144 


e 


7605 

0145 


f 


7606 

0146 


g 


7607 

0147 


h 


7610 

0150 


i 


7611 

0151 


j 


7612 

0152 


k 


7613 

0153 


1 


7614 

0154 


m 


7615 

0155 


n 


7616 

0156 


o 


7617 

0157 


p 


7620 

0160 


q 


7621 

0161 


r 


7622 

0162 


s 


7623 

0163 


t 


7624 

0164 


u 


7625 

0165 


V 


7626 

0166 


w 


7627 

0167 


X 


7630 

0170 


y 


7631 

0171 


z 


7632 

0172 


{ opening brace 

6ltt 

7633 

0173 


1 vertical line 

75 tt 

7634 

0174 


} closing brace 

62tt 

7635 

0175 


~ tilde 

76 tt 

7636 

0176 


NUL 


7640 

4000 


SOH 


7641 

0001 


STX 


7642 

0002 


ETX 


7643 

0003 


EOT 


7644 

0004 


ENQ 


7645 

0005 


ACK 


7646 

0006 


BEL 


7647 

0007 


BS 


7650 

0010 


HT 


7651 

0011 


LF 


7652 

0012 


VT 


7653 

0013 


FF 


7654 

0014 


CR 


7655 

0015 


SO 


7656 

0016 


SI 


7657 

0017 


DEL 


7637 

0177 


DLE 


7660 

0020 
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TABLE A-1. INTERACTIVE TERMINAL CHARACTER SETS (Contd) 


Character Sets 

Code Sets 



Octal 

Octal 

Octal 

ASCII Graphic 

ASCII Character 

6-Bit 

6/12-Bit 

12-Bit 

(64-Character Set) 

(128-Character Set) 

Display 

Display 

ASCII 



Code 

Codet 

Code 


DCl 



0021 


DC 2 



0022 


DC3 


7663 

0023 


DC4 


7664 

0024 


NAK 


7665 

0025 


SYN 


7666 

0026 


ETB 


7667 

0027 


CAN 


7670 

0030 


EM 


7671 

0031 


SUB 


. 7672 

0032 


ESC 


7673 

0033 


FS 


7674 

0034 


GS 


7675 

0035 


RS 


7676 

0036 


OS 


7677 

0037 

tAvailable only on NOS. 





Character or code Interpretation depends on context. Refer to Character Set Anomalies in the text. 
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TABLE A-2. 7-BIT ASCII CODE AND CHARACTER SETS 


- 128-Character Set - 

-96-Character Subset ■ 

Graphic 64-Character Subset— 



) 

0 

0 

0 

0 

1 

0 

1 

0 

0 

1 

1 

1 

0 

0 

1 

0 

1 

1 

1 

0 

1 

1 

1 

0 

1 

2 

3 

B 

5 

BB 

NUL 

DLE 

SP 

0 

@ 

P 


P 

000 

020 

040 

060 

• 100 

120 

140 

160 

SOH 

DC! 

j 

1 

A 

Q 

a 

9 

001 

021 

041 

061 

101 

121 

141 

161 

STX 

DC2 

It 

2 

B 

R 

b 

r 

002 

022 

042 

062 

102 

122 

142 

162 

ETX 

DC3 

# 

3 

C 

S 

c 

s 

003 

023 

043 

063 

103 

123 

143 

163 

EOT 

DC4 

$ 

4 

D 

T 

d 

t 

004 

024 

044 

064 

104 

124 

144 

164 

ENQ 

NAK 

% 

5 

1 

E 

U 

e 

u 

005 

025 

045 

065 

105 

125 

145 

165 

ACK 

SYN 

& 

6 

F 

V 

f 

V 

006 

026 

046 

066 

106 

126 

146 

166 

BEL 

ETB 

' 

7 

G 

W 

g 

w 

007 

027 

047 

067 

107 

127 

147 

167 

BS 

CAN 

( 

8 

H 

X 

h 

X 

010 

030 

050 

070 

110 

130 

150 

170 

HT 

EM 

) 

9 

I 

Y 

i 

y 

on 

031 

051 

071 

111 

131 

151 

171 

LF 

SUB 

A 


J 

z 

j 

Z 

012 

032 

052 

072 

112 

132 

152 

172 

VT i 

ESC 

+ 


K 

[ 

k 

{ 

013 

033 

053 

073 

113 

133 

153 

173 

FF 

FS 

» 

< 

L 

\ 

1 

i 

1 

014 

034 

054 

074 

114 

134 

154 

174 

CR 

GS 

- 

= 

M 

) 

m 

} 

015 

035 

055 

075 

115 

135 

155 

175 

SO 

RS 

. 

> 

N 

/N 

n 

~ 

016 

036 

056 

076 

U6 

136 

156 

176 

SI 

US 

/ 

7 

0 


o 

DEit 

017 

037 

057 

077 

117 

-1 

137 

157 

177 


^The graphic 95-character subset does not include DEL; refer to Terminal Transmission Modes in the text. 
LEGEND: 

Numbers under characters are the octal values for the 7-bit character codes used within the network. 
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TABLE A-3. LOCAL BATCH DEVICE CHARACTER SETS 



Character Sets 



Code Sets 




CDC 

ASCII 

ASCII 

Octal 

Octal 

Octal 

Lard Keypunch Code 

Graphic 

(64-Character 

Set) 

Graphic 

(64-Character 

Set) 

Graphic 

(95-Character 

Set) 

6-Bit 

Display 

Code 

6/12-Bit 

Display 

Codet 

12-Bit 

ASCII 

Code 

026 

029 

: colontt 

A 

: colontt 

A 

A 

oott 

01 

01 

0101 

8-2 

12-1 

8-2 

12-1 

B 

6 

B 

02 

02 

0102 

12-2 

12-2 

c 

C 

C 

03 

03 

0103 

12-3 

12-3 

D 

D 

D 

04 

04 

0104 

12-4 

12-4 

E 

E 

E 

05 

05 

0105 

12-5 

12-5 

F 

F 

F 

06 

06 

0106 

12-6 

12-6 

G 

G 

G 

07 

07 

0107 

12-7 

12-7 

H 

H 

H 

10 

10 

0110 ' 

12-8 

12-8 

I 

I 

I 

ll 

11 

0111 

12-9 

12-9 

J 

J 

J 

12 

12 

0112 

11-1 

11-1 

K 

K 

K 

13 

13 

0113 

11-2 

11-2 

L 

L 

L 

14 

14 

0114 

11-3 

11-3 

M 

M 

M 

15 

15 

0115 

11-4 

11-4 

N 

N 

N 

16 

16 

0116 

11-5 

11-5 

0 

0 

0 

17 

17 

0117 

11-6 

11-6 

P 

P 

P 

20 

20 

0120 

11-7 

11-7 

Q 

Q 

Q 

21 

21 

0121 

11-8 

11-8 

R 

R 

R 

22 

22 

0122 

11-9 

11-9 

S 

S 

S 

23 

23 

0123 

0-2 

0-2 

T 

T 

T 

24 

24 

0124 

0-3 

0-3 

U 

u 

U 

25 

25 

0125 

0-4 

0-4 

V 

V 

V 

26 

26 

0126 

0-5 

0-5 

w 

u 

w 

27 

27 

0127 

0-6 

0-6 

X 

X 

X 

30 

30 

0130 

0-7 

0-7 

Y 

Y 

Y 

31 

31 

0131 

0-8 

0-8 

z 

Z 

Z 

32 

32 

0132 

0-9 

0-9 

0 

0 

0 

33 

33 

0060 

0 

0 

1 

1 

1 

34 

34 

0061 

1 

1 

2 

2 

2 

35 

35 

0062 

2 

2 

3 

3 

3 

36 

36 

0063 

3 

3 

4 

4 

4 

37 

37 

0064 

4 

4 

5 

5 

5 

40 

40 

0065 

5 

5 

6 

6 

6 

41 

41 

0066 

6 

6 

7 

7 

7 

42 

42 

0067 

7 

7 

8 

8 

8 

43 

43 

0070 

8 

8 

9 

9 

9 

44 

44 

0071 

9 

9 

+ plus 

+ plus 

+ plus 

45 

45 

0053 

12 

12-8-6 

- hyphen (minus) 

- hyphen (minus) 

- hyphen (minus) 

46 

46 

0055 

11 

11 

* asterisk 

* asterisk 

* asterisk 

47 

47 

0052 

11-8-4 

11-8-4 , 

/ slant 

/ slant 

/ slant 

50 

50 

0057 

0-1 

0-1 

( open, paren. 

( open, paren. 

( open, paren. 

51 

51 

0050 

0-8-4 

12-8-5 

) clos. paren. 

) clos. paren. 

. ) clos. paren. 

52 

52 , 

0051 

12-8-4 

11-8-5 

$ dollar sign 

$ dollar sign 

$ dollar sign 

53 

53 

0044 

11-8-3 

11-8-3 

= equals 

= equals 

= equals 

■ 54 

54 , 

0075 

8-3 

8-6 

Space 

space 

space 

55 

55 . 

0040 

no punch 

no punch 

» comma 

, comma 

, comma 

56 

56 

0054 

0-8-3 

0-8-3 

. period 

. period 

» period 

57 

57 

0056 

12-8-3 

12-8-3 

= equivalence 

It number sign 

# number sign 

60 

60 

0043 

0-8-6 

8-3 

[ open, bracket 

[ open, bracket 

[ Open, bracket 

61 

61 = 

0133 

8-7 

12-8-2 

] clos. bracket 

] clos. bracket 

] clos. bracket 

62 

62 

0135 

0-8-2 

"l2-0ttt 

11-8-2 

Z percent slgntt 

Z percent slgntt 

Z percent slgntt 

63tt 

63tt 

0045 

8-6 

°'ii-ottt 

0-8-4 
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TABLE A-3. LOCAL BATCH DEVICE CHARACTER SETS (Contd) 



tAvailable only on NOS. 

tt Character or code interpretation depends on context. Refer to Character Set Anomalies in the text, 
ttt Available for input only, on NOS. 


^Available for input only, on NOS/BE or SCOPE 2. 
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TABLE A-4. 7-TRACK CODED TAPE CONVERSIONS 
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TABLE A-5. ASCII 9-TRACK CODED TAPE CONVERSION 



ASCII 






Code , 

Conversion' 

Character a“d 

Code ConversionTT 

ttt 

Display Code' ' ' 


Character 

Code 

(Hex) 

Character 

ASCII 

Character 

Code 

(Octal) 

20 

space 

00 

NUL 

Space 

55 

21 

! exclamation point 

7D 

} closing brace 

! exclamation point 

66 

22 

" quotation mark 

02 

STX 

" quotation mark 

64 

23 

# number sign 

03 

ETX 

# number sign 

60 

24 

$ dollar sign 

04 

EOT 

$ dollar sign 

53 

25 

% percent sign§ 

05 

ENQ . 

% percent sign® 

63® 

26 

& ampersand 

06 

ACK 

& ampersand 

67 

27 

' apostrophe 

07 

BEL 

' apostrophe 

70 

28 

( opening parenthesis 

08 

BS 

( opening parenthesis 

51 

29 

) closing parenthesis 

09 

HT 

) closing parenthesis 

52 

2A 

* asterisk 

OA 

LF 

* asterisk 

47 

2B 

+ plus 

OB 

VT 

+ plus 

45 

2C 

, comma 

OC 

FF 

, comma 

56 

2D 

- hyphen (minus) 

OD 

CR 

- hyphen (minus) 

46 

2E 

. period 

OE 

SO 

. period 

57 

2F 

/ slant 

OF 

SI 

/ slant 

50 

30 

0 

10 

DLE 

0 

33 

31 

1 

11 

DCl 

1 

34 

32 

2 

12 

DC2 

2 

35 

33 

3 

13 

DC3 

3 

36 

34 

4 

14 

DC4 

4 

37 

35 

5 

15 

NAK 

5 

40 

36 

6 

16 

SYN 

6 

41. 

37 

7 

17 

ETB 

7 

42 

38 

8 

18 

CAN 

8 

43 

39 

9 

19 

EM 

9 

44 

3A 

: colon^ 

lA 

SUB 

: colon® 

00® 

3B 

; semicolon 

IB 

ESC 

; semicolon 

77 

3C 

< less than 

7B 

{ opening brace 

< less than 

72 

3D 

= equals 

ID 

GS 

= equals 

54 

3E 

> greater than 

IE 

RS 

> greater than 

73 

3F 

? question mark 

IF 

US 

? question mark 

71 

40 

@ commercial at 

60 

' grave accent 

@ commercial at 

74 

41 

A 

61 

a 

A 

01 

42 

B 

62 

b 

B 

02 

43 

c 

63 

c 

C 

03 

44 

D 

64 

d 

D 

04 

45 

E 

65 

e 

E 

05 

46 

F 

66 

f 

F 

06 
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TABLE A-5. ASCII 9-TRACK CODED TAPE CONVERSION (Contd) 


ASCII 

6-Bit 

Display Codettt 

_ 

Code 

ConversionT 

Character and 

Code Conversiontt 

Code 




ASCII 

Code 

(Hex) 

Character 

(Hex) 

Character 

Character 

(Octal) 

47 

G 

67 

g 

G 

07 

48 

H 

68 

h 

H 

10 

49 

I 

69 

1 

I 

11 

4A 

J 

6A 

J 

J 

12 

4B 

K 

6B 

k 

K 

13 

4C 

L 

6C 

1 

L 

14 

4D 

M 

6D 

m 

M 

15 

4E 

N 

6E 

n 

N 

16 

4F 

0 

6F 

o 

0 

17 

50 

P 

70 

p 

P 

20 

51 

Q 

71 

q 

Q 

21 

52 

R 

72 

r 

R 

22 

53 

S 

73 

s 

S 

23 

54 

T 

74 

t 

T 

24 

55 

0 

75 

u 

0 

25 

56 

V 

76 

V 

V 

26 

57 

W 

77 

w 

W 

27 

58 

X 

78 

X 

X 

30 

59 

Y 

79 

y 

Y 

31 

5A 

Z 

7A 

Z 

Z 

32 

5B 

[ opening bracket 

1C 

FS 

[ opening bracket 

61 

5C 

\ reverse slant 

7C 

1 vertical line 

\ reverse slant 

75 

5D 

] closing bracket 

01 

SOH 

] closing bracket 

62 

5E 

caret 

7E 

~ tilde 

caret 

76 

5F 

underline 

7F 

DEL 

underline 

65 



_1 





Twhen these characters are copied from or to a tape, the characters remain the same and the code 
changes from or to ASCII to or from display code. 


tl^These characters do not exist in display code. When the characters are copied from a tape, each 
ASCII character is changed to an alternate display code-^character.^ The corresponding codes are also 
changed. Example: When the system copies a lowercase a; 61 (hexadecimal), from tape, it writes an 
uppercase A, 01 (octal). 

+++ 

' ''A display code space always translates to an ASCII space. 

^Character or code interpretation depends on context. Refer to Character Set Anomalies in the text. 


60499500 R 


A-15 












TABLE A-6. EBCDIC 9~TRACK CODED TAPE CONVERSION 



Code 

Conversiont 


Character 



Character and 
Code Conversi-ontt 


Character 


6-Bit 

Display Codettt 


ASCII 

Character 


40 

space 

00 

NUL 

4A 

i cent sign 

1C 

IFS 

4B 

. period 

OE 

SO 

4C 

< less than 

CO 

{ opening brace 

4D 

( opening parenthesis 

16 

BS 

4E 

+ plus 

OB 

VT 

4F 

1 vertical line 

DO 

} closing brace 

50 

& ampersand 

2E 

ACK 

5A 

! exclamation point 

01 

SOH 

5B 

$ dollar sign . 

37 

EOT 

5C 

* asterisk 

25 

LF 

5D 

) closing parenthesis 

05 

HT 

5E 

; semicolon 

27 

ESC 

5F 

“1 logical NOT 

A1 

~ tilde 

60 

- hyphen (minus) 

OD 

CR 

1 

61 

/ slant 

OF 

SI 

6B 

, comma 

OC 

FF 

6C 

% percent sign§ 

2D 

ENQ 

6D 

underline 

07 

DEL 

6E 

> greater than 

IE 

IRS 

6F 

? question mark 

IF 

lUS 

7A 

: colon§ 

3F 

SUB 

7B 

if number sign 

03 

ETX 

7C 

@ commercial at 

79 

\ reverse slant 

7D 

apostrophe 

2F 

BEL 

7E 

= equals 

ID 

IGS . 

7F 

” quotation mark 

02 

STX 

Cl 

A 

81 

a 

C2 

B 

82 

b 

C3 

C 

83 

c 

C4 

D 

84 

d 

C5 

E 

83 

e 

C6 

F 

86 

f 

C7 

G 

87 

8 

C8 

H 

88 

h 

C9 

I 

89 

i 

D1 

J 

91 

j 

D2 

K 

92 

k 

D3 

L 

93 

1 


space 

[ opening bracket 
. period 
< less than 
( opening parenthesis 
+ plus 

! exclamation point 
& ampersand 
] closing bracket 
$ dollar sign 
* asterisk 

) closing parenthesis 
; semicolon 
caret 

- hyphen (minus) 

/ slant 

, comma 

% percent sign§ 

_ underline 
> greater than 
? question mark 
: colon§ 
if number sign 
@ commercial at 
apostrophe 

- equals 

" quotation mark 

A 

B 

C 

D 

E 

F 

G 

H 

I 

J 

K 

L 


Code 
(Octal) 
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TABLE A-6. EBCDIC 9-TRACK CODED TAPE CONVERSION (Contd) 


Code 

Conversiont 

Character and 

Code Conversiontt 

Display Codettt 

ASCII 

Character 

, Code 

(Octal) 

Code 

(Hex) 

Character 

Code 

(Hex) 

Character 

D4 

M 

94 

m 

M 

15 

D5 

N 

95 

n 

N 

16 

D6 

0 

96 

o 

0 

17 

D7 

P 

97 

P 

P 

20 

D8 

Q 

98 

q 

Q 

21 

D9 

R 

99 

r 

R 

22 

EO 

\ reverse slant 

6A 

1 vertical line 

\ reverse slant 

75 

E2 

S 

A2 

s 

S 

23 

E3 

T 

A3 

t 

T 

24 

E4 

U 

A4 

u 

U 

25 

E5 

V 

A5 

V 

V 

26 

E6 

W 

A6 

w 

w 

27 

E7 

X 

A7 

X 

X 

30 

E8 

Y 

A8 

y 

Y 

31 

E9 

Z 

A9 

Z 

Z 

32 

FO 

0 

10 

DLE 

0 

33 

FI 

1 

11 

DCl 

1 

34 

F2 

2 

12 

DC2 

2 

35 

F3 

3 

13 

TM 

3 

36 

F4 

4 

3C 

DC4 

4 

37 

F5 

5 

3D 

NAK 

5 

40 

F6 

6 

32 

SYN 

6 

41 

F7 

7 

26 

ETB 

7 

42 

F8 

8 

18 

CAN 

8 

43 

F9 

9 

19 

EM 

1 

_i 

9 

_i 

44 


twhen these characters are copied from or to a tape, the characters remain the same (except EBCDIC 
codes 4A (hexadecimal), 4F (hexadecimal), 5A (hexadecimal), and 5F (hexadecimal)) and the code changes 
from or to EBCDIC to or from display code. 


ttlhese characters do not exist in display code. When the characters are copied from a tape, each 

EBCDIC character is changed to an alternate display code character. The corresponding codes are also 
changed. Example: When the system copies a lowercase a, 81 (hexadecimal), from tape, it writes an 
uppercase A, 01 (octal). 

tttA display code space always translates to an EBCDIC space. 

^Character or code interpretation depends on context. Refer to Character Set Anomalies in the text. 
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TABLE A-7. FULL EBCDIC CHARACTER SET 


Hexa¬ 

decimal 

EBCDIC 

Code 

Octal 

12-Blt 

EBCDIC 

Code 

EBCDIC 
Graphic or 
Control 
Charactert 

Hexa¬ 

decimal 

EBCDIC 

Code 

Octal 

12-Bit 

EBCDIC 

Code 

EBCDIC 

Graphic or 
Control 
Charactert 

Hexa¬ 

decimal 

EBCDIC 

Code 

Octal 

12-Bit 

EBCDIC 

Code 

EBCDIC 

Graphic or 
Control 
Charactert 

00 

0000 

NUL 

4A 

0112 

i. cent sign 

A7 

0247 

X 

01 

0001 

SOH 

4B 

0113 

. period 

A8 

0250 

y 

02 

0002 

STX 

4C 

0114 

< less than 

A9 

0251 

Z 

03 

0003 

ETX 

4D 

0115 

( open, paren. 

AA 

0252 

undefined 

04 

0004 

PF 

4E 

0116 

+ plus 

thru 

thru 


05 

0005 

HT 

4F 

0117 

1 logical OR 

BF 

0277 

undefined 

06 

0006 

LC 

50 

0120 

& ampersand 

CO 

0300 

{ open, brace 

07 

0007 

DEL 

51 

0121 

undefined 

Ci 

0301 

A 

08 

0010 

undefined 

thru 

thru 


C2 

0302 

B 

09 

0011 

undefined 

59 

0131 

undefined 

C3 

0303 

c 

OA 

0012 

SMM 

5A ■ 

0132 

! exclam, point 

C4 

0304 

D 

OB 

0013 

VT 

5B 

0133 

$ dollar sign 

C5 

0305 

E 

OC 

0014 

FF 

5C 

0134 

* asterisk 

C6 

0306 

F 

OD 

0015 

CR 

5D 

0135 

) clos. paren. 

C7 

0307 

G 

OE 

0016 

SO 

5E 

0136 

; semicolon 

C8 

0310 

H 

OF 

0017 

SI 

5F 

0137 

"1 logical NOT 

C9 

0311 

I 

10 

0020 

DLE 

60 

0140 

- minus 

CA 

0312 

undefined 

11 

0021 

DCl 

61 

0141 

/ slant' 

CB 

0313 

undefined 

12 

0022 

DC2 

62 

0142 

undefined 

CC 

0314 

j" 

13 

0023 

TM 

thru 

thru 


CD 

0315 

undefined 

14 

0024 

RES 

69 

0151 

undefined 

CE 

0316 

M 

15 

0025 

NL 

6A 

0152 

\ vertical line 

CF 

0317 

undefined 

16 

0026 

BS 

6B 

0153 

, comma 

DO 

0320 

} clos. brace 

17 

0027 

IL 

6C 

0154 

% percent sign 

D1 

0321 

j 

18 

0030 

CAN 

6D . 

0155 

underline 

D2 

0322 

K 

19 

0031 

EM 

6E 

0156 

> greater than 

D3 

0323 

L 

lA 

0032 

CC 

6F 

0157 

? question mark 

D4 

0324 

M 

IB 

0033 

GUI 

70 

0160 

undefined 

D5. 

0325 

N 

1C 

0034 

IFS 

thru 

thru 


D6 

0326 

0 

ID 

0035 

ICS 

78 

0170 

undefined 

D7 

0327 

P 

IE 

0036 

IRS 

79 

0171 

' grave accent 

D8 

0330 

Q 

IF 

0037 

lUS 

7A 

0172 

: colon 

D9 

033t 

R 

20 

0040 

DS 

7B 

0173 

# number sign 

DA 

0332 

undefined 

21 

0041 

SOS 

7C 

0174 

@ commercial at 

thru 

thru 


22 

0042 

FS 

7D 

0175 

' apostrophe 

DF 

0337 

undefined 

23 

0043 

undefined 

7E 

0176 

= equals 

EO 

0340 

\ reverse slant 

24 

0044 

BYP 

7F 

0177 

" quotation mark 

El 

0341 

undefined 

25 

0045 

LF 

80 

0200 

undefined 

E2 

0342 

s 

26 

0046 

ETBB 

81 

0201 

a 

E3 

0343 

T 

27 

0047 

ESCE 

82 

0202 

b 

E4 

0344 

u 
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TABLE A-7. FULL EBCDIC CHARACTER SET (Contd) 


Hexa¬ 

decimal 

EBCDIC 

Code 

Octal 

12-Blt 

EBCDIC 

Code 

EBCDIC 
Graphic or 
Control 
Charactert 

Hexa¬ 

decimal 

EBCDIC 

Code 

Octal 

12-Bit 

EBCDIC 

Code 

EBCDIC 

Graphic or 
Control 
Charactert 

Hexa¬ 

decimal 

EBCDIC 

Code 

Octal 

12-Bit 

EBCDIC 

Code 

EBCDIC 
Graphic or 
Control 
Charactert 

28 

0050 

undefined 


0203 

c 

E5 

0345 

V 

29 

0051 

undefined 


0204 

d 

E6 

0346 

W 

2A 

0052 

SM 

85 

0205 

e 

E7 

0347 

X 

2B 

0053 

CU2 

86 

0206 

f 

E8 

0350 

Y 

2C 

0054 

undefined 

87 

0207 

g 

E9 

0351 

Z 

2D 

0055 

ENQ 

88 

0210 

h 

EA 

0352 

undefined 

2E 

0056 

ACK 

89 

0211 

i 

' EB 

0353 

undefined 

2F 

0057 

BEL 

8A 

0212 

undefined 

EC 

0354 

H 

30 

0060 

undefined 

thru 

thru 


ED 

0355 

undefined 

31 

0061 

undefined 

90 

0220 

undefined 

thru 

thru 


32 

0062 

SYN 

91 

0221 

J 

EF 

0357 

undefined 

33 

0063 

undefined 

92 

0222 

k 

FO 

0360 

0 

34 

0064 

PN 

93 

0223 

1 

FI 

0361 

1 

35 

0065 

RS 

94 

0224 

m 

F2 

0362 

2 

36 

0066 

UC 

95 

0225 

n 

F3 

0363 

3 

37 

0067 

EOT 

96 

0226 

o 

F4 

0364 

4 

38 

0070 

undefined 

97 

0227 

p 

F5 

0365 

5 

39 

0071 

undefined 

98 

0230 

q 

F6 

0366 

6 

3A 

0072 

undefined 

99 

0231 

r 

F7 

0367 

7 

3B 

0073 

CU3 

9A 

0232 

undefined 

F8 

0370 

8 

3C 

0074 

DC4 

thru 

thru 


F9 

0372 

9 

3D 

0075 

NAK 

AO 

0240 

undefined 

FA 

0372 

1 vertical line 

3E 

0076 

undefined 

A1 

0241 

~ tilde 

■FB 

0373 

undefined 

3F 

0077 

SUB 

A2 

0242 

s 

thru 

thru 


40 

0100 

Space 

A3 

0243 

t 

FF 

0377 

undefined 

41 

0101 

undefined 

A4 

0244 

u 




thru 

thru 


A5 

0245 

V 




49 

0111 

undefined 

A6 

0246 

w 




tcraphlc 

support 

characters shown are those used on the IBM System/370 standard 
subsets or variations of this character graphic set. 

(PN) print 

train. Other devices 
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TABLE A-8. CHARACTER CODE TRANSLATIONS, CONSOLES AND LINE PRINTERS IN TERMINAL CLASSES 9, 14, 16, 17 

AND 18 (HASP, HPRE, 2780, 3270, AND 3780) 


Terminal EBCDIC 


Network 

ASCII (Normalized Mode Use) 

Hex. 

Code 

Octal 

Code 

Graphlct 

i'i’ 

Control Character'' 

Hex. 

Codettt 

Octal 

Codettt 

Graphic 

Control Charactertt 









00 

000 


NUL 

00 

000 


null 

01 

001 


SOH 

01 

001 


start of header 

02 

002 


STX 

02 

002 


start of text 

03 

003 


ETX 

03 

003 


end of text 

04 

004 


PF 

20 

040 

space 


05 

005 


HT 

09 

Oil 


horizontal tabulate 

06 

006 


LC 

20 

040 

Space 


07 

007 


DEL 

7F 

177 


delete 

08 

010 


undefined 

20 

040 

space 


09 

Oil 


undefined 

20 

040 

space 


OA 

012 


SMM 

20 

040 

Space 


OB 

013 


VT 

OB 

013 


vertical tabulate 

OC 

014 


FF 

OC 

014 


form feed 

OD 

015 


CR 

OD 

015 


carriage return 

OE 

.016 


SO 

OE 

016 


shift out 

OF 

017 


SI 

OF 

017 


shift in 

10 

020 


DLE 

10 

020 


data link escape 

11 

021 


DCl 

11 

021 


device controi 1 

12 

022 


DC2 

12 

022 


device control 2 

13 

023 


TM 

13 

023 


device control 3 

14 

024 


RES 

20 

040 

space 


15 

025 


NL 

20 

040 

space 


16 

026 


BS 

08 

010 


backspace 

17 

027 


IL 

20 

040 

space 


18 

030 


CAN 

18 

030 


cancel 

19 

031 


EM 

19 

031 


end of medium 

lA 

032 


CC 

20 

040 

space 


IB 

033 


CUl ; 

20 

040 

space 


1C 

034 


IFS 

1C 

034 


file separator 

ID 

035 


IGS 

ID 

035 


group separator 

IE 

036 


IRS 

IE 

036 


record separator 

IF 

037 


lUS 

IF 

037 


unit separator 

20 

040 


DS 

20 

040 

space 


21 

041 


SOS 

20 

040 

space 


22 

042 


FS 

20 

040 

space 


23 

043 


undefined 

20 

040 

space 


24 

044 


BYP 

20 

040 

space 


25 

045 


LF 

OA 

012 


linefeed 

26 

046 


ETB or EOB 

17 

027 


end of transmission block 

27 

047 


ESC or PRE 

IB 

033 


escape 

28 

050 


undefined 

20 

040 

space 


29 

051 


undefined 

20 

040 

space 


2A 

052 


SM 

20 

040 

space 


2B 

053 


CU2 

20 

040 

space 


2C 

054 


undefined 

20 

040 

space 


2D 

055 


ENQ . 

05 

005 


enquiry 

2E 

056 


ACK 

06 

006 


positive acknowledgment 

2F 

057 


BEL 

07 

007 


bell 

30 

060 


undefined 

20 

040 

space 


31 

061 


undefined 

20 

040 

space 


32 

062 


SYN 

16 

026 


synchronous idle 

33 

063 


undefined 

20 

040 

space 


34 

064 


PN 

20 

040 

space 


35 

065 


RS 

20 

040 

space 


36 

066 


UC 

20 

040 

space 


37 

067 


EOT 

04 

004 


end of transmission 

38 

070 


undefined 

20 

040 

space 


39 

071 


undefined 

20 

040 

space 


3A 

072 


undefined 

20 

040 

space 
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TABLE A-8. CHARACTER CODE TRANSLATIONS, CONSOLES AND LINE PRINTERS IN TERMINAL CLASSES 9, 14, 16, 17 

AND 18 (HASP, HPRE, 2780, 3270, AND 3780) (Contd) 


Terminal EBCDIC 

Network ASCII (Normalized Mode Use) 

Hex. 

Code 

Octal 

Code 

Graphlct 

Control Charactertt 

Hex. 

Codettt 

Octal 

Codettt 

Graphic 

Control Charactertt 









3B 

073 


CU3 

20 

040 

Space 


3C 

074 


DC4 

14 

024 


device control 4 

3D 

075 


NAK 

15 

025 


negative acknowledgement 

3E 

076 


undefined 

20 

040 

space 


3F 

077 


SUB 

lA 

032 


substitute 

40 

100 

Space 


20 

040 

space 


41 

101 


undefined 

20 

040 

space 


thru 

thru 







49 

111 







4A 

112 

i 


5B 

133 

[ 


4B 

113 



2E 

056 

• 


4C 

114 

< 


3C 

074 

< 


4D 

115 

{ 


28 

050 

( 


4E 

116 

+ 


2B 

053 

+ 


4F 

117 

1 


21 

041 

1 


50 

120 

& 


26 

046 

& 


51 

121 


undefined 

20 

040 

space 


thru 

thru 







59 

131 







5A 

132 

1 


50 

135 

] 


5B 

133 

$ 


24 

044 

$ 


5C 

134 

* 


2A 

052 

* 


5D 

135 

) 


29 

051 

) 


5E 

136 



3B 

073 

> 


5F 

137 

”1 


5E 

136 

/N 


60 

140 

- 


2D 

055 

- 


61 

141 

/ 


2F 

057 

/ 


62 

142 


undefined 

20 

040 

Space 


thru 

thru 







69 

151 







6A 

152 



7C 

174 

t 


6B 

153 



2C 

054 

i 


6C 

154 

X 


25 

045 

X 


6D 

155 



5F 

137 



6E 

156 

■> 


3E 

076 

> 


6F 

157 



3F 

077 

? 


70 

160 


undefined 

20 

040 

space 


thru 

thru 







78 

170 







79 

171 



60 

140 



7A 

172 

: 


7A 

172 

: 


7B 

173 

» 


23 

043 

# 


7C 

174 

@ 


40 

100 

@ 


7D 

175 



27 

047 



7E 

176 

s 


3D 

075 

= 


7F 

177 

" 


22 

042 

" 


80 

200 


undefined 

20 

040 

space 


81 

201 

a 


61 

141 

a 


82 

202 

b 


62 

142 

b 


83 

203 

c 


63 

143 

c 


84 

204 

d 


64 

144 

d 


85 

205 

e 


65 

145 

e 


86 

206 

f 


66 

146 

f 


87 

207 

g 


67 

147 

g 


88 

210 

h 


68 

150 

h 


89 

211 

i 


69 

151 

i 


8A 

212 


undefined 

20 

040 

space 


thru 

thru 







90 

220 
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TABLE A-8. CHARACTER CODE TRANSLATIONS, CONSOLES AND LINE PRINTERS IN TERMINAL CLASSES 9, 14, 16, 17 

AND 18 (HASP, HPRE, 2780, 3270, AND 3780) (Contd) 


Terminal EBCDIC 


Network 

ASCII (Normalized Mode Use) 

Hex. 

Code 

Octal 

Code 

Graphict 

Control Character^t 

Hex. 

Codettt 

Octal 

Codetn 

Graphic 

Control Character^t 

91 

221 

j 


6A 

152 

j 


92 

222 

k 


6B 

153 

k 


93 

223 

I 


6C 

154 

1 


94 

224 

m 


6D 

155 

m 


95 

225 

n 


6E 

156 

n 


96 

226 

o 


6F 

157 

o 


97 

227 

p 


70 

160 

p 


98 

230 

q 


71 

161 

q 


99 

231 

r 


72 

162 

r 


9A . 

232 


undefined 

20 

040 

space 


thru 

thru 







AO 

240 







A1 

241 



7E 

176 

— 


A2 

242 

5 


73 

163 

s 


A3 

243 

t 


74 

164 

t 


A4 

244 

U 


75 

165 

u 


A5 

245 

V 


76 

166 

V 


A6 

246 

w 


77 

167 

w 


A7 

247 

X 


78 

170 

X 


A8 

250 

y 


79 

171 

y 


A9 

251 

Z 


7A 

172 

Z 


AA 

252 


undefined 

20 

040 

Space 


thru 

thru 







BF 

277 







CO 

300 

{ 


7B 

173 

{ 


Cl 

301 

A 


41 

101 

A 


C2 

302 

B 


42 

102 

B 


C3 

303 

c 


43 

103 

C 


C4 

304 

D 


44 

104 

D 


C5 

305 

E 


45 

105 

E 


C6 

306 

F 


46 

106 

F 


C7 

307 

G 


47 

107 

G 


C8 

310 

H 


48 

110 

H 


C9 

311 

I 


49 

111 

I 


CA 

312 


undefined 

20 

040 

Space 


CB 

313 


undefined 

20 

040 

space 


CC 

314 



20 

040 

space 


CD 

315 


undefined 

20 

040 

space 


CE 

316 

V 


20 

040 

space 


CF 

317 


undefined 

20 

040 

space 


DO 

320 

} 


7E 

175 

} 


D1 

321 

J 


4A 

112 

J 


D2 

322 

K 


4B 

113 

K 


D3 

323 

L 


4C 

114 

L 


D4 

324 

M 


4D 

115 

M 


D5 

325 

N 


4E 

116 

N 


D6 

326 

0 


4F 

117 

0 


D7 

327 

P 


50 

120 

P 


D8 

330 

Q 


51 

121 

Q 


D9 

331 

R 


52 

122 

R 


DA 

332 


undefined 

20 

040 

Space 


thru 

thru 







DF 

337 







EO 

340 

\ 


5C 

134 

\ 


El 

341 


undefined 

20 

040 

space 


E2 

342 

s 


53 

123 

s 


E3 

343 

T 


54 

124 

T 


E4 

344 

U 


55 

125 

U 


E5 

345 

V 


56 

126 

V 
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TABLE A-8. CHARACTER CODE TRANSLATIONS, CONSOLES AND LINE PRINTERS IN TERMINAL CLASSES 9, 14, 16, 17, 

AND 18 (HASP, HPRE, 2780, 3270, AND 3780) (Contd) 


Terminal EBCDIC 

Network ASCII (Normalized Mode Use) 

Hex. 

Code 

Octal 

Code 

Graphic^ 

Control Charactertt 

Hex. 

Codettt 

Octal 

Codettt 

Graphic 

Control Character"^^ 



W 


57 

127 

w 




X 


58 

130 

X 


E8 


Y 


59 

131 

Y 


E9 


Z 


5A 

132 

z 


EA 

352 


undefined 

20 

040 

space 


EB 

353 


undefined 

20 

040 

space 


EC 

354 

H 


20 

040 

space 


ED 

355 


undefIned 

20 

040 

space 


thru 

thru 







EF 

357 







FO 

360 

0 


30 

060 

0 


FI 

361 

1 


31 

061 

1 


F2 

362 

2 


32 

062 

2 


F3 

363 

3 


33 

063 

3 


F4 

364 

4 


34 

064 

4 


F5 

365 

5 


35 

065 

5 


F6 

366 

6 


36 

066 

6 


F7 

367 

7 


37 

067 

7 


F8 

370 

8 


38 

070 

8 


F9 

371 

9 


39 

071 

9 


FA 

372 

1 


20 

040 

Space 


FB 

373 


undefined 

20 

040 

space 


thru 

thru 







FF 

377 







^Graphic characters shown are those used on the 

IBM System/370 standard (PN) print train. Other devices 

support subsets or variations of this character graphic set. 



ttNot used for output to 

Line printers. Translation to a space (100 octal) occurs. 

Shown with zero parity 

[eighth or uppermost bit Is always 

zero). 
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TABLE A-9, CHARACTER CODE TRANSLATIONS, ASCII CHARACTER SET CONSOLES IN 
TERMINAL CLASSES 1 THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3.64, H200n, T4014, M4D) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 



ASCII 


Hex. 

Octal 

ASCII 


Codet 

Codet 

Graphic 

Control Character! 1 

Codettl^ 

Codettt 

Graphic 

Control Character 









00 

000 


NUL or ® 

00 

000 


null 

03 

003 

A 

ETX or @ 

03 

003 


end of text 

05 

005 


ENQ or WRU or ® 

05 

005 


enquiry 

06 

006 


ACK or RU or (f) 

06 

006 


positive acknowledgement 

09 

Oil 


HT or ® 

09 

Oil 


horizontal tabulate 

OA 

012 


LF or NL or 4 or (j) 

OA 

012 


linefeed 

OC 

014 


FF or FORM or (l) 

OC 

014 


formfeed 

OF 

017 

> 

SI or 

OF 

017 


shift in 

11 

021 


DCl or X-ON or ® 

11 

021 


device control 1 

12 

022 


DC2 or TAPE or ® 

12 

022 


device control 2 

14 

024 


DC4 or TAPE or @ 

14 

024 


device control 4 

17 

027 


ETB or (w) 

17 

027 


end transmission block 

18 

030 


CAN or CLEAR or 

18 

030 


cancel 

IB 

033 


ESC or ESCAPE or (D 

IB 

033 


escape 

ID 

035 


GS or 0 

ID 

035 


group separator 

IE 

036 


RS or@ 

IE 

036 


record separator 

21 

041 

1 


21 

041 

1 


22 

042 

ti 


22 

042 



24 

044 

$ 


24 

044 

$ 


27 

047 



27 

047 



28 

050 

( 


28 

050 

( 


2B 

053 

+ 


2B 

053 

+ 


2D 

055 

- 


2D 

055 

- 


2E 

056 

, 


2E 

056 



30 

060 

0 


30 

060 

0 


33 

063 

3 


33 

063 

3 


35 

065 

5 


35 

065 

5 


36 

066 

6 


36 

066 

6 


39 

071 

9 


39 

071 

9 


3A 

072 



3A 

072 



3C 

074 

< 


3C 

074 

< 


3F 

077 

? 


3F 

077 

9 


41 

101 

A 


41 

101 

A 


42 

102 

B 


42 

102 

B 


44 

104 

D 


44 

104 

D 


47 

107 

G 


47 

107 

G 


48 

110 

H 


48 

110 

H 


4B 

113 

K 


4B 

113 

K 


4D 

115 

M 


4D 

115 

M 


4E 

116 

N 


4E 

116 

N 


50 

120 

P 


50 

120 

P 


53 

123 

S 


53 

123 

S 


55 

125 

U 


55 

125 

U 


56 

126 

V 


56 

126 

V 


59 

131 

Y 


59 

131 

Y 


5A 

132 

Z 


5A 

132 

Z 


5C 

134 

\ 


5C 

134 

\ 


5F 

137 

or ♦- 


5F 

137 



60 

140 

‘T* 


60 

140 

' 


63 

143 

c 


63 

143 

C 


65 

145 

e 


65 

145 

e 


66 

146 

f 


66 

146 

f 


69 

151 

1 


69 

151 

i 


6A 

152 

j 


6A 

152 

j 


6C 

154 

1 


6C 

154 

1 


6F 

157 

0 


6F 

157 

0 


71 

161 

9 


71 

161 

q 


72 

162 

r 


72 

162 

r 
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TABLE A-9. CHARACTER CODE TRANSLATIONS, ASCII CHARACTER SET CONSOLES IN 
TERMINAL CLASSES 1 THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3.64, H2000, T4014, M40) (Contd) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex. 

Codet 

Octal 

Codet 

ASCII 

Graphic 

Control Charactertt 

Hex. 

Codettt 

Octal 

Codettt 

ASCII 

Graphic 

Control Character 









74 

164 

t 


74 

164 

t 


77 

167 

w 


77 

167 

w 


78 

170 

X 


78 

170 

X 


7B 

173 

{ 


7B 

173 

{ 


7C 

174 

1 or t or 1 


7C 

174 

1 


7D 

175 

} 


7D 

175 

} 


7E 

176 

or “1 


7E 

176 

— 


81 

201 


SOH or ® 

01 

001 


start of header 

82 

202 


STX or @ 

02 

002 


start of text 

84 

204 


EOT or ^ 

04 

004 


end of transmission 

87 

207 


BELL or Xg) 

07 

007 


bell 

88 

210 


BS or •- or (H) 

08 

010 


backspace 

8B 

213 


VT or ® 

OB 

013 


vertical tabulate 

8D 

215 


CR or RETURN or (m) 

OD 

015 


carriage return 

8E 

216 

< 

SO or ® 

OE 

016 


shift out 

90 

220 


DLE or (^ 

10 

020 


data link escape 

93 

223 


DC3 or X-OFF or 

13 

023 


device control 3 

95 

225 


NAK or -* or (u) 

15 

025 


negative acknowledgement 

96 

226 


SYN or LINE CLEAR or © 

16 

026 


synchronous idle 

99 

231 


EM or RESET or (y) 

19 

031 


end of medium 

9A 

232 


SUB or t or (Z) 

lA 

032 


substitute 

9C 

234 


FS or Q 

1C 

034 


file separator 

9F 

237 


US or 0 

IF 

037 


unit separator 

AO 

240 

SPACE 


20 

040 

space 




or 








blank 






A3 

243 

# 


23 

043 

It 


A5 

245 

X 


25 

045 

% 


A6 

246 

& 


26 

046 

& 


A9 

251 

) 


29 

051 

) 


AA 

252 

* 


2A 

052 

A 


AC 

254 



2C 

054 

» 


AF 

257 

/ 


2F 

057 

/ 


B1 

261 

1 


31 

061 

1 


B2 

262 

2 


32 

062 

2 


B4 

264 

4 


34 

064 

4 


B7 

267 

7 


37 

067 

7 


B8 

270 

8 


38 

070 

8 


BB 

273 



3B 

073 

> 


BD 

275 



3D 

075 

= 


BE 

276 

> 


3E 

076 

> 


CO 

300 

@ 


40 

100 

@ 


C3 

303 

C 


43 

103 

C 


C5 

305 

E 


45 

105 

E 


C6 

306 

F 


46 

106 

F 


C9 

311 

I 


49 

111 

I 


CA 

312 

J 


4A 

112 

J 


CC 

314 

L 


4C 

114 

L 


CF 

317 

0 


4F 

117 

0 


D1 

321 

Q 


51 

121 

Q 


D2 

322 

R 


52 

122 

R 


D4 

324 

T 


54 

124 

T 


D7 

327 

W 


57 

127 

W 


D8 

330 

X 


58 

130 

X 


DB 

333 

[ 


5B 

133 

[ 


DD 

335 

] 


5D 

135 

1 


DE 

336 

A or —1 


5E 

136 

A 


El 

341 

a 


61 

141 

a 
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TABLE A-9. CHARACTER CODE TRANSLATIONS, ASCII CHARACTER SET CONSOLES IN 
TERMINAL CLASSES 1 THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3.64, H2000, T4014, M40) (Contd) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex. 

Octal 

ASCII 

Control Charactertt 

Hex. 

Octal 

ASCII 


Codet 

Codet 

Graphic 

Codettt 

Codettt 

Graphic 

Control Character 

E2 

342 

b 


62 

142 



E4 

344 

d 


64 

144 



E7 

347 

g 


67 

147 

8 


E8 

350 

h 


68 

150 

h 


EB 

353 

k 


6B 

153 

k 


ED 

355 

m 


6D 

155 

m 


EE 

356 

n 


6E 

156 

n 


FO . 

360 

p 


70 

160 

P 


F3 

363 

s 


73 

163 

s 


F5 

365 

u 


75 

165 

u 


F6 

366 

V 


76 

166 

V 


F9 

371 

y 


79 

171 

y 


FA 

372 

Z 


7A 

172 

Z 


FF 

1 

377 

_ 

■ 

DEL or RUBOUT 

7F 

177 


delete 

tShown with even parity, which is the default for these terminal classes 

(unless PA=N or PA=I, an appli- 

cation program receives the same code as in normalized mode). 




t^A circle around a character indicates that the character key is pressed 

In conjunction with a CTL, CTRL, 

CNTRL, or CONTROL key to generate the code. 





tttshown with zero parity (eighth or uppermost bit is always zero). 
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TABLE A-10, CHARACTER CODE TRANSLATIONS, APL TYPEWRITER-PAIRING CONSOLES IN 
TERMINAL 1 CLASSES THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3,64, H2000, T4014, M40) 


Terminal ASCII (Transparent Mode Use) 


Hex 
Code' 

Octal 

Codet 

ASCII-A. 

Graph! 




74 

164 

T 

77 

167 

W 

78 

170 

X 

7B 

173 

{ 

7C 

174 

—1 

7D 

175 

} 

7E 

176 

$ 

81 

201 


82 

202 


84 

204 


87 

207 


88 

210 


8B 

213 


8D 

215 


8E 

216 


90 

220 


93 

223 


95 

225 


96 

226 


99 

231 


9A 

232 


9C 

234 


9F 

237 


AO 

240 

SPACE 

or 

blank 

A3 

243 

< 

A5 

245 

= 

A6 

246 

> 

A9 

251 

A 

AA 

252 


AC 

254 


AF 

257 

/ 

B1 

261 

1 

B2 

262 

2 

B4 

264 

4 

B7 

267 

7 

B8 

270 

8 

BB 

273 

[ 

BD 

275 

X 

BE 

276 

: 

CO 

300 


C3 

303 

n 

C5 

305 

€ 

C6 

306 


C9 

311 

\ 

CA 

312 

0 

CC 

314 

□ 

CF 

317 

o 

D1 

321 

? 

D2 

322 

p 

D4 

324 


D7 

327 

CaJ 

D8 

330 


DB 

333 

♦- 

DD 

335 


DE 

336 

> 

El 

341 

A 


SOH or ^ 

STX or @ 

EOT or 
BELL or 
BS or *- or 
VT or 

CR or RETURN or @ 

SO or 

DLE or (J) 

DC3 or X-OFF or @ 

NAK or -► or (ff) 

SYN or LINE CLEAR or (v) 
EM or RESET or (y) 

SUB or t or 
FS or 0 
US or R| 



Network 7 

ISCII (Normalized Mode Use) 

Hex 

Octal 

ASCII-APL „ , 

Codettt 

Codettt 

^ . Control Character 

Graphic 

54 

124 . 

T 

57 

127 

W 

58 

130 

X 

7B 

173 

{ 

6B 

153 

-H 

7D 

175 

} 

24 

044 

$ 

01 

001 

start of header 

02 

002 

start of text 

04 

004 

end of transmission 

07 

007 

bell 

08 

010 

backspace 

OB 

013 

vertical tabulate 

OD 

015 

carriage return 

OE 

016 

shift out 

10 

020 

data link escape 

13 

023 

device control 3 

15 

025 

negative acknowledgement 

16 

026 

synchronous idle 

19 

031 

end of medium 

lA 

032 

substitute 

1C 

034 

file separator 

IF 

037 

unit separator 

20 

040 

space 

3C 

074 

< 

3D 

075 


3E 

076 

> 

26 

046 

A 

22 

042 


2C 

054 

> 

2F 

057 

/ 

31 

061 

1 

32 

062 

2 

34 

064 

4 

37 

067 

7 

38 

070 

8 

5B 

133 

1 

66 

146 

X 

3A 

072 


5E 

136 

— 

63 

143 

n 

65 

145 

e 

5F 

137 


69 

151 

i 

6A 

152 

o 

6C 

154 

□ 

6F 

157 

o 

3F 

077 

7 

72 

162 

P 

74 

164 

- 

77 

167 

to 

78 

170 


70 

160 


71 

161 

-► 

7C 

174 

> 

41 

101 

A 
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TABLE A-10, CHARACTER CODE TRANSLATIONS, APL TYPEWRITER-PAIRING CONSOLES IN 
TERMINAL 1 CLASSES THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3.64, H2000, T4014, M40) (Contd) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex 

Codet 

Octal 

Codet 

ASCII-APL 

Graphic 

Control Charactertt 

Hex 

Codettt 

Octal 

Codettt 

ASCII-APL 

Graphic 

Control Character 

00 

000 


NUL or 0 

00 

000 


null 

03 

003 

▲ 

ETX or 0 

03 

003 


end of text 

05 

005 


ENQ or WRU or @ 

05 

005 


enquiry 

06 

006 


ACK or RU or (F) 

06 

006 


positive acknowledgement 

09 

Oil 


HT or © 

09 

Oil 


horizontal tabulate 

OA 

012 


LF or NL or 1 or (J) 

OA 

012 


linefeed 

OC 

014 


FF or FORM or (^L) 

OC 

014 


formfeed 

OF 

017 

► 

SI or (o) 

OF 

017 


shift in 

11 

021 


DCl or X-ON or © 

11 

021 


device control 1 

12 

022 


DC2 or TAPE or © 

12 

022 


device control 2 

14 

024 


DC4 or TAPE or © 

14 

024 


device control 4 

17 

027 


ETB or (?) 

17 

027 


end transmission block 

18 

030 


CAN or CLEAR or © 

18 

030 


cancel 

IB 

033 


ESC or ESCAPE or (T) 

IB 

033 


escape 

ID 

035 


GS or © 

ID 

035 


group separator 

IE 

036 


RS or 

IE 

036 


record separator 

21 

041 

• 


23 

043 



22 

042 

) 


29 

052 



24 

044 

< 


40 

100 

< 


27 

047 

] 


5D 

135 

] 


28 

050 

V 


21 

041 

V 


2B 

053 

+ 


25 

045 

+ 


2D 

055 



2B 

053 



2E 

056 

• 


2E 

056 ■ 



30 

060 

0 


30 

060 

0 


33 

063 

3 


33 

063 

3 


35 

065 

5 


35 

065 

5 


36 

066 

6 


36 

066 

6 


39 

071 

9 


39 

071 

9 


3A 

072 

( 


28 

050 

( 


3C 

074 

> 


3B 

073 



3F 

077 

\ 


5C 

134 

\ 


41 

101 

OC 


61 

141 

OC 


42 

102 

i 


62 

142 

i 


44 

104 

L 


64 

144 

L 


47 

107 

V 


67 

147 

V 


48 

110 

A 


68 

150 

A 


4B 

113 



27 

047 



4D 

115 

1 


6D 

155 

1 


4E 

116 

T 


6E 

156 

T 


50 

120 

* 


2A 

052 

* 


53 

123 

r 


73 

163 

r 


55 

125 



75 

165 

i 


56 

126 

u 


76 

166 

u 


59 

131 

t 


79 

171 

t 


5A 

132 

c 


7A 

172 

<= 


5C 

134 

h- 


7E 

176 



5F 

137 

- 


2D 

055 

- 


60 

140 

0 


60 

140 

0 


63 

143 

c 


43 

103 

C 


65 

145 

E 


45 

105 

E 


66 

I46 

F 


46 

106 

F 


69 

151 

I 


47 

111 

I 


6A 

152 

J 


4A 

112 

J 


6C 

154 

L 


4C 

114 

L 


6F 

157 

0 


4F 

117 

0 


71 

161 

Q 


51 

121 

Q 


72 

162 

R 


52 

122 

R 
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TABLE A-10. CHARACTER CODE TRANSLATIONS, APL TYPEWRITER-PAIRING CONSOLES IN 
TERMINAL CLASSES 1 THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3.64, H2000, T4014, M40) (Contd) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex 

Octal 

ASCII-APL „ , .+ 



ASCII-APL 


Codet 

Codet 

Graphic Control CharacterTt 

Codettt 

Codettt 

Graphic 

Control Character 

E2 

342 

B 

42 

HPI 

B 


E4 

344 

D 

44 


D 


E7 

347 

G 

47 

107 

G 


E8 

350 

H 

48 

no 

H 


EB 

353 

K 

4B 

113 

K 


ED 

355 

M 

4D 

115 

M 


EE 

356 

N 

4E 

116 

N 


FO 

360 

P 

50 

120 

P 


F3 

363 

S 

53 

123 

S 


F5 

365 

U 

55 

125 

u 


F6 

366 

V 

56 

126 

V 


F9 

371 

Y 

59 

131 

Y 


FA 

372 

Z 

5A 

132 

Z 


FF 

377 

DEL or RUBOUT 

7F 

177 


delete 

tshown with even parity, which is the default for 

these terminal classes (unless PA=N or PA=I, an 

application 

program receives the same code as in normalized mode)* 



tTA circle around a character indicates that the character key 

is pressed in conjunction with a CTL, CTRL, 

CNTRL, or CONTROL key to generate the code. 





tttshown with zero parity (eighth or uppermost bit is always zero). 
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TABLE A-11. CHARACTER CODE TRANSLATIONS, APL BIT-PAIRING CONSOLES IN TERMINAL 
CLASSES 1 THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3.6A, H200n, T4014, AND M40) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex 

Code! 

Octal 

Codet 

ASCII-APL 

Graphic 

Control Charactertt 

Hex 

Codettt 

Octal 

Codettt 

ASCII-APL 

Graphic 

Control Character 









00 

000 


NUL or @ 

00 

000 


nul 1 

03 

003 

A 

ETX or @ 

03 

003 


end of text 

05 

005 


ENQ or WRU or @ 

05 

005 


enquiry 

06 

006 


ACK or RU or (f) 

06 

006 


positive acknowledgement 

09 

on 


HT or @ 

09 

on 


horizontal tabulate 

OA 

012 


LF or NL or 1 or 

OA 

012 


linefeed 

OC 

014 


FF or FORM or (l) 

OC 

014 


formfeed 

OF 

017 

> 

SI or ® 

OF 

017 


shift In 

11 

021 


DCl or X-ON or ® 

11 

021 


device control 1 

12 

022 


DC2 or TAPE or m 

12 

022 


device control 2 

14 

024 


DC4 or TAPE or (p 

14 

024 


device control 4 

17 

027 


ETB or (w) 

17 

027 


end transmission block 

18 

030 


CAN or CLEAR or 

18 

030 


cancel 

IB 

033 


ESC or ESCAPE or (T) 

IB 

033 


escape 

ID 

035 


GS or 0 

ID 

035 


group separator 

IE 

036 


RS or 

IE 

036 


record separator 

21 

041 

. • 


23 

043 



22 

042 

_ 


5E 

136 

_ 


24 

044 

< 


40 

100 

< 


27 

047 

> 


3E 

076 

> 


28 

050 



22 

042 



2B 

053 

( 


28 

050 

( 


2D 

055 

+ 


2B 

053 

+ 


2E 

056 

, 


2E 

056 



30 

060 

0 


30 

060 

0 


33 

063 

3 


33 

063 

3 


35 

065 

5 


35 

065 

5 


36 

066 

6 


36 

066 

6 


39 

071 

9 


39 

071 

9 


3A 

072 

] 


5D 

135 

] 


3C 

074 



3B 

073 



3F 

077 

\ 


5C 

134 

\ 


41 

101 

cc 


61 

141 

OC 


42 

102 

i 


62 

142 

i 


44 

104 

L 


64 

144 

L 


47 

107 

V 


67 

147 

V 


48 

no 

A 


68 

150 

A 


4B 

113 

' 


27 

047 

' 


4D 

115 

1 


6D 

155 

1 


4E 

116 

T 


6E 

156 

T 


50 

120 

* 


2A 

052 

* 


53 

123 

r 


73 

163 

r 


55 

125 



75 

165 

i 


56 

126 

u 


76 

166 

0 


59 

131 

t 


79 

171 

t 


5A 

132 

c: 


7A 

172 

<r 


5C 

134 

0 


60 

140 

0 


5F 

137 



26 

046 

/N 


60 

140 



71 

161 



63 

143 

c 


43 

103 

c 


65 

145 

E 


45 

105 

E 


66 

146 

F 


46 

106 

F 


69 

151 

I 


49 

111 

I 


6A 

152 

j 


4A 

112 

J 


6C 

154 

L 


4C 

114 

L 


6F 

157 

0 


4F 

117 

0 


71 

161 

Q 


51 

121 

Q 


72 

162 

R 


52 

122 

R 
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TABLE A-10. CHARACTER CODE TRANSLATIONS, APL TYPEWRITER-PAIRING CONSOLES IN 
TERMINAL 1 CLASSES THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3.64, H2000, T40U, M40) (Contd) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex 

Codet 

Octal 

Codet 

ASCII-APL 
Graphic 

Control Charactertt 

Hex 

CodeTtt 

Octal 

Codettt 

ASCII-APL 

Graphic 

Control Character 

74 

164 

T 


54 

124 

T 


77 

167 

W 


57 

127 

W 


78 

170 

X 


58 

130 

X 


7B 

173 

-H 


6B 

153 



7C 

174 

$ 


24 

044 

$ 


7D 

175 

} 


7D 

160 

} 


7E 

176 



25 

045 



81 

201 


SOH or ® 

01 

001 


start of header 

82 

202 


STX or m 

02 

002 


start of text 

84 

204 


EOT or 

04 

004 


end of transmission 

87 

207 


BELL 

07 

007 


bell 

88 

210 


BS or ♦- or (h) 

08 

010 


backspace 

8B 

213 


VT or @ 

OB 

013 


vertical tabulate 

8D 

215 


CR or RETURN or (m) 

OD 

015 


carriage return 

8E 

216 

< 

SO or 

OE 

016 


shift out 

90 

220 


OLE or 

10 

020 


data link escape 

93 

223 


DC3 or X-OFF or (?) 

13 

023 


device control 3 

95 

225 


NAK or -► or (u) 

15 

025 


negative acknowledgement 

96 

226 


SYN or LINE CLEAR or (v) 

16 

026 


synchronous idle 

99 

231 


EM or RESET or (?) 

19 

031 


end of medium 

9A 

232 


SUB or t or (z) 

lA 

032 


substitute 

9C 

234 


FS or © 

1C 

034 


file separator 

9F 

237 


US or 0 

IF 

037 


unit separator 

AO 

240 

SPACE 


20 

040 

Space 




or 








blank 






A3 

243 

< 


3C 

074 

< 


A5 

245 



3D 

075 

= 


A6 

246 

> 


7C 

174 

> 


A9 

251 

N/ 


21 

041 

v 


AA 

252 

) 


29 

051 

) 


AC 

254 

> 


2C 

054 

> 


AF 

257 

/ 


2F 

057 

/ 


B1 

261 

1 


31 

061 

1 


B2 

262 

2 


32 

062 

2 


B4 

264 

4 


34 

064 

4 


B7 

267 

7 


37 

067 

7 


B8 

270 

8 


38 

070 

8 


BB 

273 

[ 


5B 

133 

[ 


BD 

275 

- 


2D 

055 

- 


BE 

276 



3A 

072 



CO 

300 



70 

160 



C3 

303 

n 


63 

143 

n 


C5 

305 

e 


65 

145 

e 


C6 

306 



5F 

137 



C9 

311 

I 


69 

151 

■\ 


CA 

312 

0 


6A 

152 

o 


CC 

314 

□ 


6C 

154 

□ 


CF 

317 

o 


6F 

157 

o 


D1 

321 

? 


3F 

077 

7 


D2 

322 

p 


72 

162 

p 


D4 

324 

- 


74 

164 

— 


D7 

327 

w 


77 

167 



D8 

330 

=> 


78 

170 

o 


DB 

333 

1— 


7E 

176 

1— 


DD 

335 

{ 


7B 

173 

{ 


DE 

336 

X 


66 

146 

X 


El 

341 

A 


41 

101 

A 
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TABLE A-11. CHARACTER CODE TRANSLATIONS, APL BIT-PAIRING CONSOLES IN TERMINAL 
CLASSES 1 THROUGH 3 AND 5 THROUGH 8 (M33, 713, 721, X3.64, H2000, T4014, AND M40) (Contd) 



Terminal ASCII (Transparent Mode Use) 


Network ASCII (Normalized Mode Use) 

Hex 

Code! 

Octal 

Codet 

ASCII-APL 

Graphic 

Control Charactertt 

Hex 

Codettt 

Octal 

Codettt 

ASCII-APL 

Graphic 

Control Character 

E2 

E4 

E7 

E8 

EB 

ED 

EE 

FO 

F3 

F5 

F6 

F9 

FA 

FF 

342 

344 

347 

350 

353 

355 

356 
360 
363 

365 

366 

371 

372 
377 

B 

D 

G 

H 

K 

M 

N 

P 

S 

U 

V 

Y 

Z 

■ 

DEL or RUBOUT 

42 

44 

47 

48 

4B 

4D 

4E 

50 

53 

55 

56 

59 

5A 

7F 

102 

104 

107 

110 

113 

115 

116 

120 

123 

125 

126 

131 

132 

177 

B 

D 

G 

H 

K 

M 

N 

P 

S 

U 

V 

Y 

Z 

_ 

delete 

tshown with even parity, 
cation program receives 

which is the default for these terminal classes (unless PA=N or PA=I, an appli- 
the same code as in normalized mode). 

circle around a character indicates that the character key is pressed in conjunction with a CTL, CTRL, 
CNTRL, or CONTROL key to generate the .code. 

^^^Shown with zero parity (eighth or uppermost bit is always zero). 
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TABLE A-12, CHARACTER CODE TRANSLATIONS, ASCII CONSOLES AND LINE PRINTERS IN 
TERMINAL CLASSES 10 AND 15 (200UT AND 734) 



Terminal 

ASCIlt 


Network ASCII (Normalized Mode Use) 

Hex. 

Codett 

Octal 

Codett 

Keyboard or 
Printer Graphic 

Input or 

Output 

Console Output Only 

Graphic 

ASCII 

CDC 

Hex. 

Codettt 

Octal 

Codettt 

Hex. 

Codettt 

Octal 

Codettt 

20 

040 

blank 

blank 

20 

040 



space 

23 

043 

if 


23 

043 



# 

25 

045 

% 

% 

25 

045 



X 

26 

046 

& 


26 

046 



& 

29 

051 

) 

) 

29 

051 



) 

2A 

052 

* 

* 

2A 

052 



* 

2C 

054 

t 

> 

2C 

054 



> 

2F 

057 

/ 

/ 

2F 

057 



/ 

31 

061 

1 

1 

31 

061 



1 

32 

062 

2 

2 

32 

062 



2 

34 

064 

4 

4 

34 

064 



4 

37 

067 

7 

7 

37 

067 



7 

38 

070 

8 

8 

38 

070 



8 

3B 

073 

; 

» 

3B 

073 



> 

3D 

075 

= 

= 

3D 

075 



= 

3E 

076 

> 

> 

3E 

076 



> 

40 

100 


_< 

40 

100 

60 

140 

@ 

43 

103 

c 

C 

43 

103 

63 

143 

C 

45 

105 

E 

E 

45 

105 

65 

145 

E 

46 

106 

F 

F 

46 

106 

66 

146 

F 

49 

111 

I 

I 

49 

111 

69 

151 

I 

4A 

112 

J 

J 

4A 

112 

6A 

152 

J 

4C 

114 

L 

L 

4C 

114 

6C 

154 

L 

4F 

117 

0 

0 

4F 

117 

6F 

157 

0 

51 

121 

Q 

Q 

51 

121 

71 

161 

Q 

52 

122 

R 

R 

52 

122 

72 

162 

R 

54 

124 

T 

T 

54 

124 

74 

164 

T 

57 

127 

W 

W 

57 

127 

77 

167 

W 

58 

130 

X 

X 

58 

130 

78 

170 

X 

5B 

133 

( 

[ 

5B 

133 

7B 

173 

[ 

5D 

135 

1 

] 

5D 

135 

7D 

175 

J 

5E 

136 



5E 

136 

7E 

176 


A1 

241 

j 


21 

041 



j 

A2 

242 

It 


22 

042 



II 

A4 

244 

$ 

$ 

24 

044 



$ 

A7 

247 

' 


27 

047 



' 

A8 

250 

( 

( 

28 

050 



( 
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TABLE A-12. CHARACTER CODE TRANSLATIONS, ASCII CONSOLES AND LINE PRINTERS IN 
TERMINAL CLASSES 10 AND 15 (200UT AND 734) (Contd) 


Terminal ASCIlt 

Network ASCII (Normalized Mode Use) 

Hex. 

Codett 

Oc tal 

Keyboard or 
Printer Graphic 

Input or 

Output 

Console Output Only 

Graphic 

Code!1 

ASCII 

CDC 

Hex, 

Octal 

Hex. 

Octal 



Codettt 

Codettt 

Codettt 

Codettt 


AB 

253 

+ 

+ 

2B 

053 



+ 

AD 

255 

- 

- 

2D 

055 



- 

AE 

256 

. 

• 

2E 

056 



• 

BO 

260 

0 

0 

30 

060 



0 

B3 

263 

3 

3 

33 

063 



3 

B5 

265 

5 

5 

35 

065 



5 

B6 

266 

6 

6 

36 

066 



6 

B9 

271 

9 

9 

39 

071 



9 

BA 

272 

: 


3A 

072 




BC 

274 

< 

< 

3C 

074 



< 

BF 

277 



3F 

077 



? 

Cl 

301 

A 

A 

41 

101 

61 

141 

A 

C2 

302 

B 

B 

42 

102 

62 

142 

B 

C4 

304 

D 

D 

44 

104 

64 

144 

D 

C7 

307 

G 

G 

47 

107 

67 

147 

G 

C8 

310 

H 

H 

48 

110 

68 

150 

H 

CB 

313 

K 

K 

4B 

113 

6B 

153 

K 

CD 

315 

M 

M 

4D 

115 

6D 

155 

M 

CE 

316 

N 

N 

4E 

116 

6E 

156 

N 

DO 

320 

P 

P 

50 

120 

70 

160 

P 

D3 

323 

S 

S 

53 

123 

73 

163 

S 

D5 

325 

U 

U 

55 

125 

75 

165 

U 

D6 

326 

V 

V 

56 

126 

76 

166 

V 

D9 

331 

Y 

Y 

59 

131 

79 

171 

Y 

DA 

332 

Z 

Z 

5A 

132 

7A 

172 

z 

DC 

334 

\ 

> 

5C 

134 

7C 

174 

\ 

DF 

337 

■ — 

r* 

5E 

135 

7F 

177 

- 

^Escape codes are not listed. 







tt Shown 

with odd parity, the only possible parity selection for these terminal classes. ASCII 

control 

codes 

000 through 040o (without parity) 

are removed from input during complete 

editing; codes Olg 

and 03g (SOH and ETX, without 

parity) are preserved as data in full-ASCII mode, 

as are escape code 

sequences. 








I^ttshown 

with zero parity (eighth or uppermost bit is always zero). 

During output 

, codes 000 through 

OIOq are converted 

to code 040e (blank) 

codes 0123 , 

0158, and 0378 (LF, CR, and US) are 


removed. Codes for lowercase 

ASCII characters sent to the console 

are converted to the codes tor 

the equivalent uppercase characters supported by the 

terminal, as 

shown. 
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TABLE A-13. CHARACTER CODE TRANSLATIONS, EXTERNAL BINARY CODED (BCD) CONSOLES 
AND LINE PRINTERS IN TERMINAL CLASSES 10 AND 15 (200UT and 734) 


Terminal External BCot 

Network. ASCII (Normalized Mode Use) 

Hex. 

Oc tal 

Keyboard or 
Printer Graphic 

Input or 

Output 

Console Output Only 

Graphic 

Code)f 

Codett 

ASCII 

CDC 

Hex. 

Codettt 

Octal 

Codettt 

Hex. 

Codettt 

Octal 

Codettt 

10 

020 



3A 

072 




20 

040 

- 

- 

2D 

055 



- 

23 

043 

L 

L 

4C 

114 

6C 

154 

L 

25 

045 

N 

N 

4E 

116 

6E 

156 

N 

26 

046 

0 

0 

4F 

117 

6F 

157 

0 

29 

051 

R 

R 

52 

122 

72 

162 

R 

2A 

052 

1 

s/ 

21 

041 



» 

2C 

054 

* 

* 

2A 

052 



A 

2F 

057 

> 

> 

3E 

076 



> 

31 

061 

A 

A 

41 

101 

61 

141 

A 

32 

062 

B 

B 

42 

102 

62 

142 

B 

34 

064 

D 

D 

44 

104 

64 

144 

D 

37 

067 

G 

G 

47 

107 

67 

147 

G 

38 

070 

H 

H 

48 

no 

68 

150 

H 

3B 

073 

. 

. 

2E 

056 



• 

3D 

075 



5C 

134 

7C 

174 

\ 

43 

103 

3 

3 

33 

063 



3 

45 

105 

5 

5 

35 

065 



5 

46 

106 

6 

6 

36 

066 



6 

49 

111 

9 

9 

39 

071 



9 

4A 

112 

0 

0 

30 

060 



0 

4C 

114 

= 

it 

22 

042 



II 

4F 

117 

[ 

[ 

5B 

133 

7B 

173 

[ 

51 

121 

/ 

/ 

2F 

057 



/ 

52 

122 

S 

S 

53 

123 

73 

163 

S 

54 

124 

U 

u 

55 

125 

75 

165 

u 

57 

127 

X 

X 

58 

130 

78 

170 

X ' 

58 

130 

Y 

Y 

59 

131 

79 

171 

Y 

5B 

133 

> 

, 

2C 

054 



. 

5D 

135 


r* 

5F 

137 

7F 

177 

_ 

5E 

136 

It 

s 

23 

043 



# 

A1 

241 

J 

J 

4A 

112 

6A 

152 

J 

A2 

242 

K 

K 

4B 

113 

6B 

153 

K 

A4 

244 

M 

M 

4D 

115 

6D 

155 

M 

A7 

247 

P 

P 

50 

120 

70 

160 

P 

A8 

250 

Q 

Q 

51 

121 

71 

161 

Q 

AB 

253 

$ 

$ 

24 

044 



$ 
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TABLE A-13. CHARACTER CODE TRANSLATIONS, EXTERNAL BINARY CODED (BCD) CONSOLES 
AND LINE PRINTERS IN TERMINAL CLASSES 10 AND 15 (200UT and 734) (Contd) 


Terminal External BCDt 


Network ASCII (Normalized Mode Use) 


Hex. 

Codett 

Oc tal 

Keyboard or 
Printer Graphic 

Input or 

Output 

Console Output Only 

Code!t 

ASCII 

CDC 

Hex. 

Codettt 

Octal 

Codettt 

Hex. 

Codetit 

Octal 

Codettt 

AD 

255 

' 

t 

27 

047 



AE 

256 

7 

1 

3F 

077 



B3 

263 

c 

C 

43 

103 

63 

143 

B5 

265 

E 

E 

45 

105 

65 

145 

B6 

266 

F 

F 

46 

106 

66 

146 

B9 

271 

I 

I 

49 

111 

69 

151 

BA 

272 

< 

< 

3C 

074 



BC 

274 

) 

) 

29 

051 



BF 

277 

; 

) 

3B 

073 



Cl 

301 

1 

1 

31 

061 



C2 

302 

2 

2 

32 

062 



C4 

304 

4 

4 

34 

064 



C7 

307 

7 

7 

37 

067 



C8 

310 

8 

8 

38 

070 



CB 

313 

= 

= 

3D 

075 



CD 

315 

(? 

_< 

40 

100 

60 

140 

CE 

316 

% 

% 

25 

045 



DO 

320 

blank 

blank 

20 

040 



D3 

323 

T 

T 

54 

124 

74 

164 

D5 

325 

V 

V 

56 

126 

76 

166 

D6 

326 

‘ w 

W 

57 

127 

77 

167 

D9 

331 

z 

Z 

5A 

132 

7A 

172 

DA 

332 

] 

] 

5D 

135 

7D 

175 

DC 

334 

( 

( 

28 

050 



DF 

337 

& 

/N 

26 

046 



DO 

320 

/N or 

—1 or 



5E, 

136, 



blank 

■ or 



7E 

176 




none 







tps cape codes and control codes are not listed, 
ttshown with odd parity, the only possible parity selection for these terminal classes. 

tttshown with zero parity (eighth or uppermost bit is always zero). During output, codes 000 through 
0370 are converted to code 320g (blank). Codes for lowercase ASCII characters sent to the console 
are converted to the codes for the equivalent uppercase characters supported by the terminal, as 
shown. 

^Input and output of this symbol is not possible on some terminals. BCD transmission conventions 
support the rubout symbol ■ as an internal terminal memory parity error indicator instead. The ASCII 
codes 136g and 1768 are output as a blank. 
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TABLE A-14. CHARACTER CODE TRANSLATIONS, CONSOLES AND LINE PRINTERS 
IN TERMINAL CLASSES 11, 12, AND 13 (711, 714, AND 714X) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex. 

Codet 

Octal 

Codet 

ASCII 

Graphic 

Control Charactertt 

Hex. 

Codettt 

Octal 

Codettt 

ASCII 

Graphic 

Control Character^ 

01 

001 


SOH or ® 

01 

001 


Start of header§^ 

02 

002 


STX or @ 

20 

040 

Space 


04 

004 


EOT or ^ 

20 

040 

space 


07 

007 


BELL or Tg) 

20 

040 

space 


08 

010 


BS or ♦- or (h) 

20 

040 

space 


OB 

013 


VT or 0 

OB 

013 


vertical tabulate 

OD 

015 


CR or RETURN or (M) 





OE 

016 


SO or 0^ 

OE 

016 


shift out 

10 

020 


DLE or 10 

10 

020 


data link escape 

13 

023 


DC3 or X-OFF or @ 

13 

023 


device control 3 

15 

025 


NAK or -* or 0 

15 

025 


negative acknowledgment 

16 

026 


SYN or LINE CLEAR or @ 

16 

026 


synchronous idle 

19 

031 


EM or RESET or (y) 

19 

031 


end of medium 

lA 

032 


SUB or t or Cz) 

lA 

032 


substitute 

1C 

034 


FS or (0 

1C 

034 


file separator 

IF 

037 


US or 0 

20 

040 

space 


20 

040 

SPACE 


20 

040 

space 




or 








blank 






23 

043 

it 


23 

043 

it 


25 

045 

% 


25 

045 

X 


26 

046 

& 


26 

046 

& 


29 

051 

) 


29 

051 

) 


2A 

052 

* 


2A 

052 

* 


2C 

054 



2C 

054 

> 


2F 

057 

/ 


2F 

057 

/ 


31 

061 

1 


31 

061 

1 


32 

062 

2 


32 

062 

2 


34 

064 

4 


34 

064 



37 

067 

7 


37 

067 

7 


38 

070 

8 


38 

070 

8 


3B 

073 



3B 

073 

; 


3D 

075 



3D 

075 

a 


3E 

076 

> 


3E 

076 

> 


40 

100 



40 

100 

@ 


43 

103 

C 


43 

103 

c 


45 

105 

E 


45 

105 

E 


46 

106 

F 


46 

106 

F 


49 

111 

I 


49 

111 

I 


4A 

112 

J 


4A 

112 

J 


4C 

114 

L 


4C 

114 

L 


4F 

117 

0 


4F 

117 

0 


51 

121 

Q 


51 

121 

Q 


52 

122 

R 


52 

122 

R 


54 

124 

T 


54 

124 

T 


57 

127 

W 


57 

127 

W 


58 

130 

X 


58 

130 

X 


5B 

133 

[ 


5B 

133 

1 


5D 

135 

] 


5D 

135 

1 


5E 

136 

/s or “1 


5E 

136 

/S 


61 

141 

a 


61 

141 

a 


62 

142 

b 


62 

142 

b 


64 

144 

d 


64 

144 

d 


67 

147 

g 


67 

147 

g 


68 

150 

h 


68 

150 

h 


6B 

153 

k 


6B 

153 

k 


6D 

155 

m 


6D 

155 

m 


6E 

156 

n 


6E 

156 

n 


70 

160 

p 


70 

160 

p 
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TABLE A-14. CHARACTER CODE TRANSLATIONS, CONSOLES AND LINE PRINTERS 
IN TERMINAL CLASSES 11, 12, AND 13 (711, 714, AND 714X) (Contd) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex, 

Code! 

Octal 

Codet 

ASCII 

Graphic 

Control Charactertt 

Hex. 

Codettt 

Octal 

Codettt 

ASCII 

Graphic 

Control Character^ 

73 

163 

s 


73 

163 

s 


75 

165 

u 


75 

165 

u 


76 

166 

V 


76 

166 

V 


79 

171 

y 


79 

171 

y 


7A 

172 

Z 


7A 

172 

Z 


7C 

174 

1 or t or 1 


7C 

174 

1 


7F 

177 

■ 

DEL or RUBOUT 

7F 

177 


delete 

80 

200 


NUL or @ 

20 

040 

Space 


83 

203 


ETX or @ 

03 

003 


end of text^S 

85 

205 


ENQ or WRU or @ 

20 

040 

space 


86 

206 


ACK or RU or (fJ 

20 

040 

space 


89 

211 


HT or CT) 

09 

Oil 


horizontal tabulate 

8A 

212 


LF or NL or i or (j) 

OA 

012 


linefeed 




or NEW LINE 





8C 

214 


FF or FORM or (l) 

OC 

014 


formfeed 

8F 

217 


SI or (o) 

OF 

017 


shift in 

91 

221 


DCl or X-ON or ® 

11 

021 


device control 1 

92 

222 


DC2 or TAPE or m 

12 

022 


device control 2 

94 

224 


DC4 or TAPE or m 

14 

024 


device control 4 

97 

227 


ETB or Cw) 

17 

027 


end transmission block 

98 

230 


CAN or CLEAR or @ 

18 

030 


cancel 

9B 

233 


ESC or ESCAPE or (T) 

IB 

033 


escape 

9D 

235 


GS or ^ 

ID 

035 


group separator 

9E 

236 


RS or 

IE 

036 


record separator 

A1 

241 

j 


21 

041 

f 


A2 

242 

11 


22 

042 

11 


A4 

244 

$ 


24 

044 

$ 


A7 

247 



27 

047 



A8 

250 

( 


28 

050 

( 


AB 

253 

+ 


2B 

053 

+ 


AD 

255 

- 


2D 

055 



AE 

256 

. 


2E 

056 

* 


BO 

260 

0 


30 

060 

0 


B3 

263 

3 


33 

063 

3 


B5 

265 

5 


35 

065 

5 


B6 

266 

6 


36 

066 

6 


B9 

271 

9 


39 

071 

9 


BA 

272 



3A 

072 



BC 

274 

< 


3C 

074 

< 


BF 

277 

? 


3F 

077 

9 


Cl 

301 

A 


41 

101 

A 


C2 

302 

B 


42 

102 

B 


C4 

304 

D 


44 

104 

D 


C7 

307 

G 


47 

107 

G 


C8 

310 

H 


48 

110 

H 


CB 

313 

K 


4B 

113 

K 


CD 

315 

M 


4D 

115 

M 


CE 

316 

N 


4E 

116 

M 


DO 

320 

P 


50 

120 

P 


D3 

323 

S 


53 

123 

S 


D5 

325 

u 


55 

125 

u 


D6 

326 

V 


56 

126 

V 


D9 

331 

Y 


59 

131 

Y 


DA 

332 

z 


5A 

132 

Z 


DC 

334 

\ 


5C 

134 

s/ 


DF 

337 

or 


5F 

137 



EO 

340 

' 


60 

140 



E3 

343 

c 


63 

143 

c 



A-38 


60499500 T 














TABLE A-14. CHARACTER CODE TRANSLATIONS, CONSOLES AND LINE PRINTERS 
IN TERMINAL CLASSES 11. 12, AND 13 (711, 714, AND 714K) (Contd) 


Terminal ASCII (Transparent Mode Use) 

Network ASCII (Normalized Mode Use) 

Hex. 

Codet 

Octal 

Codet 

ASCII 

Graphic 

Control Charactertt 

Hex. 

Codettt 

Octal 

Codettt 

— 

— 

ASCII 

Graphic 

Control Character^ 

E5 

345 

e 


mm 

■9 



E6 

346 

f 






E9 ' 

351 

1 


69 




EA 

352 

i 


6A 




EC 

354 

1 


6C 

154 



EF 

357 

O 


6F 

157 

0 


FI 

361 

q 


71 

161 

q 


F2 

362 

r 


72 

162 

r 


F4 

364 

t 


74 

164 

t 


F7 

367 

w 


77 

167 

w 


F8 

370 

X 


78 

170 

X 


FB 

373 

{ 


7B 

173 

{ 


FD 

375 

} 


7D 

175 

} 


FE 

376 

” or —1 


7E 

176 



tShown with odd parity, the only possible parity selection for 

these terminal classes. 

ttA circle around a character indicates that the character key is pressed 

in conjunction with a CTL, CTRL, 

CNTRL, or CONTROL key to 

generate the code. 





tttshown with zero parity (eighth or uppermost bit is always zero). 



^Converted to a space (040g) within a batch printer file. 




§§Converted to a space (OAOg) during complete editing 
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TABLE A-15. ASCII CHARACTER CODE TRANSLATIONS, EBCD CONSOLES IN TERMINAL CLASS 4 (2741) 




Terminal 

EBCD 




Network 

ASCII 

(Normalized Mode Use) 


Hex. 




Hex. 


Octal 

ASCII 



Code^ 

Codet 


Control Character 

Codettt 

Code+tt 

Graphic 

Uontroi Lnaracter 

01 

001 


or 



5F 

or 

2D 

137 

or 

055 


or 




02 

002 

i 

or 

@ 


21 

or 

40 

140 

or 

100 

' 

or 

@ 



04 

004 

* 

or 

8 


2A 

or 

38 

052 

or 

070 

* 

or 

8 



07 

007 

H 

or 

h 


48 

or 

68 

no 

or 

150 

H 

or 

h 



08 

010 


or 

4 


3A 

or 

34 

072 

or 

064 


or 

4 



OB 

013 

D 

or 

d 


44 

or 

64 

104 

or 

144 

D 

or 

d 



OD 

015 




RES or RESTORE 

00 



000 






null 


OE 

016 




BY or BYPASS 

00 



000 






null 


10 

020 

< 

or 

2 


3C 

or 

32 

074 

or 

062 

< 

or 

2 



13 

023 

B 

or 

b 


42 

or 

62 

102 

or 

142 

B 

or 

b 



15 

025 




undefIned 

00 



000 






null 


16 

026 




undefined 

00 



000 






null 


19 

031 

0 

or 

o 


4F 

or 

6F 

117 

or 

157 

0 

or 

0 



lA 

032 

W 

or 

w 


57 

or 

77 

127 

or 

167 

W 

or 

w 



1C 

034 




UCS or UPPERCASE 

OE 



016 






shift out§ 


IF 

037 




LCS or LOWERCASE 

OF 



017 






shift in§ 


20 

040 

= 

or 

1 


3D 

or 

31 

075 

or 

061 

= 

or 

1 



23 

043 

A 

or 

a 


41 

or 

61 

101 

or 

141 

A 

or 

a 



25 

045 

R 

or 

r 


52 

or 

72 

122 

or 

162 

R 

or 

r 



26 

046 

z 

or 

z 


5A 

or 

7A 

132 

or 

172 

Z 

or 

z 



29 

051 

N 

or 

n 


4E 

or 

6E 

116 

or 

i56 

N 

or 

n 



2A 

052 

V 

or 

V 


56 

or 

76 

126 

or 

166 

V 

or 

V 



2C 

054 




RO or READER STOP 

14 



024 






device control 4 


2F 

057 




HT or TAB 

09 



Oil 






j horizontal tabulate 1 

31 

061 

L 

or 

1 


4C 

or 

6C 

114 

or 

154 

L 

or 

1 



32 

062 

T 

or 

t 


54 

or 

74 

124 

or 

164 

T 

or 

t 



34 

064 

It 

or 

# 


22 

or 

23 

042 

or 

043 

= 

or 

# 



37 

067 

“I 

or 



5E 

or 

2E 

136 

or 

056 


or 




38 

070 

> 

or 

7 


3E 

or 

37 

076 

or 

067 

> 

or 

7 



3B 

073 

G 

or 

g 


47 

or 

67 

107 

or 

147 

G 

or 

g 



3D 

075 




IL or IDLE or NULL 

00 



000 






null 


3E 

076 




PRE or PREFIX 

01 



001 






start of headers 


40 

100 

1 Space 


20 



040 



Space 



43 

103 

+ 

or 

6. 


2B 

or 

26 

053 

or 

046 

+ 

or 

& 



45 

105 

Q 

or 

q 


51 

or 

71 

121 

or 

161 

Q 

or 

q 



46 

106 

Y 

or 

y 


59 

or 

79 

131 

or 

171 

Y 

or 

y 



49 

111 

M 

or 

m 


4D 

or 

6D 

115 

or 

155 

M 

or 

m 



4A 

112 

U 

or 

u 


55 

or 

75 

125 

or 

165 

U 

or 

u 



4C 

114 




PN or PUNCH ON 

11 



021 






device control 1 

(tape on) 

4F 

117 




PF or PUNCH OFF 

13 



023 






device control 3 

(tape off) 

51 

121 

K 

or 

k 


4B 

or 

6B 

113 

or 

153 

K 

or 

k 



52 

122 

S 

or 

s 


53 

or 

73 

123 

or 

163 

S 

or 

s 



54 

124 

) 

or 

0 


29 

or 

30 

051 

or 

060 

) 

or 

0 



57 

127 




undefined 

00 



000 






null 


58 

130 


or 

6 


27 

or 

36 

047 

or 

066 


or 

6 



5B 

133 

F 

or 

f 


46 

or 

66 

106 

or 

146 

F 

or 

f 



5D 

135 




BS or BACKSPACE 

08 



010 






backspace 


5E 

136 




EOB 

17 



027 






end transmission 

block^ 

61 

141 

J 

or 

j 


4A 

or 

6A 

112 

or 

152 

J 

or 

j 



62 

142 

? 

or 

/ 


3F 

or 

2F 

077 

or 

057 


or 

/ 



64 

144 

( 

or 

9 


28 

or 

39 

050 

or 

071 

( 

or 

9 



67 

147 

I 

or 

i 


49 

or 

69 

111 

or 

151 

I 

or 

i 



68 

150 

% 

or 

5 


25 

or 

35 

045 

or 

065 

% 

or 

5 



6B 

153 

E 

or 

e 


45 

or 

65 

105 

or 

145 

E 

or 

e 



6D 

155 




NL or CR or RETURN 

OD 



015 






carriage return 


6E 

156 




LF or LINE FEED 

OA 



012 






linefeed 
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TABLE A-15. ASCII CHARACTER CODE TRANSLATIONS, EBCD CONSOLES IN TERMINAL CLASS 4 (2741) (Cqntd) 




Terminal 

EBCD 

Network ASCII (Normalized Mode Use) 

Hex, 

Octal 

— 

Control Character 

Hex, 

Octal 

ASCII 

Control Character 

Codet 

Codet 


Codettt 

Codettt 

Graphic 

70 

EM 

; or 3 


3B or 33 

— 

073 or 063 

; or 3 


73 


C or c 


43 or 63 

103 or 143 

C or c 


75 


! or $ 


21 or 24 

041 or 044 

! or $ 


76 

166 

1 or , 


7C or 2C 

174 or 054 

1 or , 


79 

171 

P or p 


50 or 70 

120 or 160 

P or p 


7A 

172 

X or X 


58 or 78 

130 or 170 

X or X 


7C 

174 


EOT 

04 

004 


end of transmissions 

7F 

177 


DEL 

7F 

177 


delete 

00 

000 

space 


5B thru 5D 

133 thru 

[ or \ 







135 

or ] 


00 

000 

space 


60 

140 

' 


00 

000 

space 


7B 

173 

{ 


00 

000 

space 


7D or 7E 

175 or 176 

} or ~ 


3D 

075 


IL or IDLE or NULLS* 

02 

002 


start of text 

3D 

075 


IL or IDLE or NULl|| 

03 

003 


end of text 

3D 

075 


IL or IDLE or NULL** 

05 

005 


enquire 

3D 

075 


IL or IDLE or NDLL*| 

07 

007 


bell 

3D 

075 


IL or IDLE or NULL*® 

IL or IDLE or NULL§§ 

OB or OC 

013 or 014 


vertical tabulate 
or formfeed 

3D 

075 


10 

020 


data link escape 

3D 

075 


IL or IDLE or NULL§§ 

12 

022 


device control 2 

3D 

075 


IL or IDLE or NULL§§ 

14 thru 16 

024 thru 


device control 4, 




IL or IDLE or NDLL§§ 


026 


negative acknowledge, 
or synchronize 

3D 

075 


18 thru IF 

030 thru 


cancel, end of media. 






037 


substitute, escape, 
file separator, 
group separator, 
record separator, 
or unit separator 

tshovm with 

odd parity 

; odd parity is the default for this terminal class. 


^Each input 

line is assumed to begin in lowercase. Input characters 

are translated to lowercase ASCII 

characters 

unless prefixed by the DCS code. 

Once a case shift occurs, it remains in effect until another 

case shift 

code is received, the page width is reached. 

or the line 

is transmitted to the host computer. 

During output, case is preserved by insertion of case shift codes where needed. 

tttshown with 

zero parity (eighth or uppermost bit is always zero). 



§Not 

transmitted to the host computer after 

translation during input 

• 


^^Output translation only. 
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TABLE A-16. APL CHARACTER CODE TRANSLATIONS, EBCD CONSOLES IN TERMINAL CLASS 4 (2741) 


Terminal EBCD-APL 




Network 

ASCII (Normalized Mode Use) 

Hex. 

Code' 

Octal 

Codet 

EBCD-APL 

Graphictt 

Control Character 

Hex. 

Code^^tt 

Octal 

Codettt 

ASCII-APL 

Graphic 

Control Character 

01 

001 


or 



5F 

or 

2D 

137 

or 

053 

or 

+ 


02 

002 


or 



71 

or 

70 

161 

or 

160 

-♦ or 



04 

004 


or 

8 


22 

or 

38 

042 

or 

070 

# or 

8 


07 

007 

A 

or 

H 


68 

or 

48 

150 

or 

110 

A or 

H 


08 

010 

< 

or 

4 


40 

or 

34 

100 

or 

064 

< or 

4 


OB 

013 

L 

or 

D 


64 

or 

44 

144 

or 

104 

L or 

D 


OD 

015 




undefined 

00 



000 





null 

OE 

016 




undefined 

00 



000 





null 

10 

020 

- 

or 

2 


2D 

or 

32 

055 

or 

062 

- or 

2 


13 

023 

i 

or 

B 


42 

or 

62 

142 

or 

102 

1 or 

B 


15 

025 




undefined 

00 



000 





null 

16 

026 




undefined 

00 



000 





null 

19 

031 

<3) 

or 

0 


6F 

or 

4F 

157 

or 

117 

o or 

0 


lA 

032 

CJ 

or 

W 


77 

or 

57 

167 

or 

127 

CO or 

w 


1C 

034 




UCS or UPPERCASE 

OE 



016 





shift outi 

IF 

037 




LCS or LOWERCASE 

OF 



017 





shift ln§ 

20 

040 

f 1 

or 

1 


22 

or 

31 

042 

or 

061 

" or 

1 


23 

043 

cc 

or 

A 


61 

or 

41 

141 

or 

101 

oc or 

A 


25 

045 

p 

or 

R 


72 

or 

52 

162 

or 

122 

P or 

R 


26 

046 

c 

or 

Z 


7A 

or 

5A 

172 

or 

132 

<= or 

Z 


29 

051 

T 

or 

N 


6E 

or 

4E 

156 

or 

116 

r or 

N 


2A 

052 

u 

or 

V 


76 

or 

56 

166 

or 

126 

U or 

V 


2C 

054 




undefined 

00 



000 





null 

2F 

057 




HT or TAB 

06 



006 





horizontal tabulate 

31 

061 

□ 

or 

L 


6C 

or 

4C 

154 

or 

114 

□ or 

L 


32 

062 

- 

or 

T 


74 

or 

54 

164 

or 

124 

~ or 

T 


34 

064 

) 

or 

] 


29 

or 

5D 

051 

or 

135 

) or 

] 


37 

067 


or 

, 


3A 

or 

2E 

072 

or 

056 

: or 

. 


38 

070 

> 

or 

7 


3E 

or 

37 

076 

or 

067 

> or 

7 


3B 

073 

V 

or 

G 


67 

or 

47 

147 

or 

107 

V or 

G 


3D 

075 




IL or IDLE or NULL 

00 



000 





null 

3E 

076 




PRE or PREFIX 

IB 



033 





escape 

40 

100 

1 Space 



20 



040 



space 



43 

103 

+ 

or 

X 


25 

or 

66 

045 

or 

146 

+ or 

X 


45 

105 

7 

or 

Q 


3F 

or 

51 

077 

or 

121 

? or 

Q 


46 

106 

t 

or 

Y 


79 

or 

59 

171 

or 

131 

t or 

Y 


49 

111 

1 

or 

M 


6D 

or 

4D 

155 

or 

115 

1 or 

M 


4A 

112 

; 

or 

U 


75 

or 

55 

165 

or 

125 

i or 

U 


4C 

114 




undefined 

00 



000 





null 

4F 

117 




undefined 

00 



000 





nul 1 

, 51 

121 

—i 

or 

K 


6B 

or 

4B 

153 

or 

113 

or 

K 


52 

122 

r 

or 

S 


73 

or 

53 

163 

or 

123 

r or 

S 


54 

124 


or 

0 


26 

or 

30 

046 

or 

060 

/v or 

0 


57 

127 




undefined 

00 



000 





null 

58 

130 

> 

or 

6 


1C 

or 

36 

174 

or 

066 

> or 

6 


5B 

133 

— 

or 

F 


5E 

or 

46 

136 

or 

106 

“ or 

F 


5D 

135 




BS or BACKSPACE 

08 



010 





backspace 

5E 

136 




EOB 

17 



027 





end transmission block® 

61 

141 

o 

or 

J 


6A 

or 

4A 

152 

or 

112 

o or 

J 


62 

142 

\ 

or 

/ 


5C 

or 

2F 

134 

or 

057 

\ or 

/ 


64 

144 


or 

9 


21 

or 

39 

041 

or 

071 

X or 

9 


67 

147 

\ 

or 

I 


69 

or 

49 

151 

or 

111 

i or 

I 


68 

150 

= 

or 

5 


3D 

or 

35 

075 

or 

065 

» or 

5 


6B 

153 

e 

or 

E 


65 

or 

45 

145 

or 

105 

€ or 

E 


6D 

155 




NL or CR or RETURN 

OD 



015 





carriage return 

6E 

156 




LF or LINE FEED 

OA 



012 





line feed 

70 

160 

< 

or 

3 


3C 

or 

33 

074 

or 

063 

< or 

3 


73 

163 

n 

or 

C 


63 

or 

43 

143 

or 

103 

n or 

C 


75 

165 

( 

or 

[ 


28 

or 

5B 

050 

or 

133 

( or 

[ 


76 

166 


or 



3B 

or 

2C 

073 

or 

054 

; or 



79 

171 

* 

or 

P 


2A 

or 

50 

052 

or 

120 

* or 

P 


7A 

172 


or 

X 


78 

or 

58 

170 

or 

130 

or 

X 
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TABLE A-16. APL CHARACTER CODE TRANSLATIONS, EBCD CONSOLES IN TERMINAL CLASS 4 (2741) (Contd) 


Terminal EBCD-APL 

Network ASCII (Normalized Mode Use) 



EBCD-APL 

Control Character 

Hex. 

Octal 

ASCII-APL 

Control Character 

CodeT 

Codet 

Graphictt 

Codettt 

Codettt 

Graphic 

7C 

174 


EOT 

04 

004 


end of transmission? 

7F 

177 


DEL 

7F 

177 


delete 

00 

000 

space?? 


27 

047 

' 


00 

000 

space?? 


60 

140 

0 


00 

000 

Space” 


7B 

173 

{ 


00 

000 

spaceS^ 

IL or IDLE or NULL?? 

7D 

175 

} 


3D 

075 

02 

002 


start of text 

3D 

075 


IL or IDLE or NULL?? 

03 

003 


end of text 

3D 

075 


IL or IDLE or NULL?? 

05 

005 


enquire 

3D 

075 


IL or IDLE or NULL?” 

07 

007 


bell 

3D 

075 


IL or IDLE or NULL?? 

IL or IDLE or NULL?? 

OB or OC 

013 or 014 


vertical tabulate 
or form feed 

3D 

075 


10 thru 16 

020 thru 


data link escape. 






026 


device control 1 thru 
device control 4, 
negative acknowledge, 
or synchronize 

3D 

075 


IL or IDLE or NULL?? 

18 thru IF 

030 thru 


cancel, end of media. 






037 


substitute, escape 
file separator, 
group separator, 
record separator, 
or unit separator 

^Shown with 

odd parity; odd parity is the default for this 

terminal class. 


ttEach Input 

line is assumed to begin in lowercase. Input 

characters are translated to lowercase ASCII 

characters 

unless prefixed by the UCS code* 

Once a case 

shift occurs 

, Lt remains in effect until another 

case shift 

code is received, the page width is reached, or the line is transmitted to the host computer. 

During output, case is preserved by insertion of case shift codes where needed. 


tttshovm with 

zero parity (eighth or uppermost bit is always 

zero). 



^Not 

transmitted to the host computer after translation during input. 



^^Output translation only. 






60499500 R 


A-43 






















TABLE A-17. ASCII CHARACTER CODE TRANSLATIONS, CORRESPONDENCE 
CODE CONSOLES IN TERMINAL CLASS 4 (2741) 


Terminal Correspondence Code 


Network ASCII (Normalized Mode Use) 


Hex. Octal Correspondence 
Code^ Codet Code Graphictt 


Control Character 


Codettt Codettt Graphic 


Control Character 


1/4 or 1/2 
T or t 
$ or 4 
? or / 

% or 5 
P or p 


@ or 2 


I or i 
K or k 


+ or 1 
G or g 
S or s 
H or h 
R or r 
D or d 


V or V 
U or u 
( or 9 


space 
J or j 
0 or o 
Lori 


N or n 
Z or z 

^ or 6 
Q or q 


M or m 
X or X 
) or 0 
Y or y 
& or 7 


If or 3 
F of f 
W or w 


RES or RESTORE 
BY or BYPASS 


undefined 

undefined 


DCS or UPPERCASE 
LCS or LOWERCASE 


RO or READER STOP 
HT or TAB 


IL or IDLE or NULL 
PRE or PREFIX 


PN or PUNCH ON 


PF or PUNCH OFF 


undefined 


BS or BACKSPACE 
EOB 


NL or CR or RETURN 
LF or LINE FEED 


5B or 5D 

54 or 74 

24 or 34 
3F or 2F 

25 or 35 
50 or 70 
00 

00 

40 or 32 
2B or 3D 
00 
00 

49 or 69 
4B or 6B 
OE 
OF 

7C or 31 

47 or 67 
53 or 73 

48 or 68 
52 or 72 

44 or 64 
14 

09 

56 or 76 

55 or 75 
28 or; 39 
5F or 2D 
2A or 38 
2C 

00 

IB 

20 

4A or 6A 
4F or 6F 
4C or 6C 
22 or 27 

45 or 65 
11 


2E 

4E or 6E 
5A or 7A 
00 

21 or 36 
51 or 71 
08 
17 

4D or 6D 
58 or 78 
29 or 30 
79 or 59 
26 or 37 
3A or 3B 
OD 
OA 

23 or 33 
46 or 66 
57 or 77 


137 or 135 

124 or 164 
044 or 064 
077 or 057 
045 or 065 
120 or 160 
000 

000 

100 or 062 
053 or 075 
000 
000 

111 or 151 

113 or 153 
016 

017 

174 or 061 
107 or 147 
123 or 163 
110 or 150 
122 or 162 

104 or 144 
024 

Oil 

126 or 166 

125 or 165 
050 or 071 
137 or 055 
052 or 070 
054 

000 

033 

040 

112 or 152 
117 or 157 

114 or 154 
042 or 041 

105 or 145 


or 156 
or 172 


or 066 
or 161 


or 155 
or 170 
or 060 
or 171 
or 067 
or 073 


or 063 
or 146 
or 167 


T or t 
$ or 4 
? or / 
% or 5 
P or p 


@ or 2 


1 or 1 
K or k 


; or 1 
G or g 
S or s 
H or h 
R or r 
D or d 


V or V. 
U or u 
( or 9 
_ or - 
* or 8 


space 
J or j 
0 or o 
L or 1 


shift out® 
shift ln§ 


device control 4 
horizontal tabulate 


null 

escape 


device control 1 
(tape on) 
device control 3 
(tape off) 


N or n 
Z or z 

! or 6 
Q or q 


M or m 
X or X 
) or 0 
Y or y 
& or 7 


If or 3 
F or f 
W or w 


backspace 

end transmission block^ 


carriage return 
line feed 
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TABLE A-17. ASCII CHARACTER CODE TRANSLATIONS, CORRESPONDENCE 
CODE CONSOLES IN TERMINAL CLASS 4 (2741) (Contd) 


Terminal Correspondence Code 


Network ASCII 


(Normalized Mode Use) 



Octal 

Code! 

Correspondence 
Code Graphlctt 

Control Character 

Hex. 

Codettt 

Octal 

Codettt 

ASCII 

Graphic 

Control Character 









76 

WM 

B or b 

1 

j 

42 or 62 

102 or 142 

B or b 


79 


A or a 


41 or 61 

101 or 141 

A or a 


7A 

172 

C or c 


43 or 63 

103 or 143 

C or c 


7C 

174 


EOT 

04 

004 


end of transmission® 

7F 

177 


DEL 

18 

030 


cancel 

00 

000 

soace®^ 


27 

047 



00 

000 

spacers 


5C 

134 

\ 


00 

000 

space®® 


5E 

136 



00 

000 

space§§ 


60 

140 

' 


00 

000 

space§§ 


7B 

173 

{ 


00 

000 

space®® 


7D or 7E 

175 or 176 

} or - 


3D 

075 


IL or IDLE or NULL®® 

01 

001 


start of header 

3D 

075 


IL or IDLE or NULL®® 

02 

002 


start of text 

3D 

075 


IL or IDLE or null®® 

03 

003 


end of text 

3D 

075 


IL or IDLE or NULL®® 

05 

005 


enquire 

3D 

075 


IL or IDLE or NULL®® 

07 

007 


bell 

3D 

075 


IL or IDLE or NULL®® 

OB or OC 

013 or 014 


vertical tabulate 








or form feed 

3D 

075 


IL or IDLE or NULL®® 

10 

020 


data link escape 

3D 

075 


IL or IDLE or NULL®® 

12 

022 


device control 2 

3D 

075 


IL or IDLE or NULL®® 

14 thru 16 

024 thru 


device control 4, 






026 


negative acknowledge, 








or synchronize 

3D 

075 


IL or IDLE or NULL®® 

18 thru IF 

030 thru 


cancel, end of media. 






037 


substitute, 








file separator, 








group separator. 








record separator, 

i 


_1 





or unit separator 


tshown with odd parity; odd parity Is the default for this terminal class. 

++ 

'Each Input line is assumed to begin in lowercase. Input characters are translated to lowercase ASCII 
characters unless prefixed by the UCS code. Once a case shift occurs, it remains in effect until another 
case shift code Is received, the page width Is reached, or the line is transmitted to the host computer. 
During output, case is preserved by insertion of case shift codes where needed. 

+ + + 

'''Shown with zero parity (eighth or uppermost bit is always zero). 

§Not transmitted to the host computer after translation during input. 

Output translation only. 
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TABLE A-18. APL CHARACTER CODE TRANSLATIONS, CORRESPONDENCE 
CODE CONSOLES IN TERMINAL CLASS 4 (2741) 



Terminal 

Correspondence Code 



Network ASCII 

(Normalized Mode Use) 

Hex 

Code' 

Octal 

Codet 

Correspondence 
Code APL 
Graphictt 

Control Character 

Hex 

Cpdettt 

Octal 

Codettt 

ASCII-APL 

Graphic 

Control Character 









01 

001 


or 



71 

or 

70 

161 

or 

160 


or 



02 

002 

- 

or 

T 


74 

or 

54 

164 

or 

124 


or 

T 


04 

004 

< 

or 

4 


40 

or 

34 

100 

or 

064 

< 

or 

4 


07 

007 

\ 

or 

/ 


5C 

or 

2F 

134 

or 

057 

\ 

or 

/ 


08 

010 

a 

or 

5 


3D 

or 

35 

075 

or 

065 

= 

or 

5 


OB 

013 

it 

or 

P 


2A 

or 

50 

052 

or 

120 

* 

or 

P 


OD 

015 




undefined 

00 



000 






null 

OE 

016 




undefined 

00 



000 






null 

10 

020 


or 

2 


5E 

or 

32 

136 

or 

062 


or 

2 


13 

023 

+ 

or 

X 


25 

or 

66 

045 

or 

146 

+ 

or 

X 


15 

025 




undefined 

00 



000 






null 

16 

026 

\ 



undefined 

00 



000 






null 

19 

031 

or 

I 


69 

or 

49 

151 

or 

111 

\ 

or 

I 


lA 

032 


or 

K 


27 

or 

4B 

153 

or 

113 


or 

K 

shift out® 

1C 

034 




DCS or UPPERCASE 

OE 



016 






IF 

037 




LCS or LOWERCASE 

OF 



017 






shift in§ 

20 

040 

ti 

or 

1 


23 

or 

31 

042 

or 

061 

It 

or 

1 


23 

043 

V 

or 

G 


67 

or 

47 

147 

or 

107 

V 

or 

G 


25 

045 

r 

or 

S 


73 

or 

53 

163 

or 

123 

r 

or 

S 


26 

046 

A 

or 

H 


68 

or 

48 

150 

or 

110 

A 

or 

H 


29 

051 

P 

or 

R 


72 

or 

52 

162 

or 

122 

P 

or 

R 


2A 

052 

L 

or 

D 


64 

or 

44 

144 

or 

104 

L 

or 

D 


2C 

054 




undefined 

00 



000 






null 

2F 

057 




HT or TAB 

09 



Oil 






horizontal tabulate 

31 

061 

u 

or 

V 


76 

or 

56 

166 

or 

126 

0 

or 

V 


32 

062 


or 

U 


75 

or 

55 

165 

or 

125 

i 

or 

U 


34 

064 

\/ 

or 

9 


21 

or 

39 

041 

or 

071 


or 

9 


37 

067 

- 

or 

+ 


2D 

or 

2B 

055 

or 

053 


or 

+ 


38 

070 


or 

8 


22 

or 

38 

042 

or 

070 


or 

8 


3B 

073 

> 

or 

> 


3B 

or 

2C 

073 

or 

054 


or 



3D 

075 




IL or IDLE or NULL 

00 



000 






null 

3E 

076 




PRE or PREFIX 

IB 



033 






escape 

40 

100 

space 



20 



040 



space 


43 

103 

0 

or 

J 


6A 

or 

4A 

156 

or 

112 

o 

or 

J 


45 

105 

O 

or 

0 


6F 

or 

4F 

157 

or 

117 

O 

or 

0 


46 

106 

□ 

or 

L 


6C 

or 

4C 

154 

or 

114 

□ 

or 

L 


49 

111 

) 

or 

] 


29 

or 

5D 

051 

or 

035 

) 

or 

] 


4A 

112 

€ 

or 

E 


65 

or 

45 

145 

or 

105 

€ 

or 

E 


4C 

114 




undefined 

00 



000 






null 

4F 

117 




undefined 

13 



023 






null 

51 

121 

: 

or 



3A 

or 

2E 

072 

or 

056 


or 



52 

122 

T 

or 

N 


6E 

or 

4E 

156 

or 

116 

T 

or 

N 


54 

124 

cz 

or 

Z 


7A 

or 

5A 

172 

or 

132 


or 

Z 


57 

127 




undefined 

00 



000 






null 

58 

130 

> 

or 

6 


7C 

or 

36 

174 

or 

066 

> 

or 

6 


5B 

133 


or 

Q 


3F 

or 

51 

077 

or 

121 

9 

or 

Q 


5D 

135 




BS or BACKSPACE 

08 



010 






backspace 

5E 

136 




EOB 

17 



027 






end transmission 
block§ 

61 

141 

i 

or 

M 


6D 

or 

4D 

155 

or 

115 

1 

or 

M 


62 

142 

=> 

or 

X 


78 

or 

58 

170 

or 

130 

O 

or 

X 


64 

144 

/N 

or 

0 


26 

or 

30 

045 

or 

060 

✓s 

or 

0 


67 

147 

t 

or 

Y 


79 

or 

59 

171 

or 

131 

t 

or 

Y 


68 

150 

> 

or 

7 


3E 

or 

37 

076 

or 

067 

> 

or 

7 


6B 

153 

( 

or 

[ 


28 

or 

5B 

050 

or 

133 

( 

or 

[ 


6D 

155 




NL or CR or RETURN 

OD 



015 






carriage return 

6E 

156 




LF or LINE FEED 

OA 



012 






line feed 

70 

160 

< 

or 

3 


3C 

or 

33 

074 

or 

063 

< 

or 

3 


73 

163 


or 

F 


5F 

or 

46 

137 

or 

106 


or 

F 


75 

165 

CJ 

or 

w 


77 

or 

57 

167 

or 

127 

a; 

or 

W 
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TABLE A-18. APL CHARACTER CODE TRANSLATIONS, CORRESPONDENCE 
CODE CONSOLES IN TERMINAL CLASS 4 (2741) (Contd) 


Terminal Correspondence Code 

Network ASCII 

(Normalized Mode Use) 

Hex 

Codet 

Octal 

Codet 

Correspondence 
Code APL 

Graphlctt 

Control Character 

Hex 

Codettt 

Octal 

Codettt 

ASCII-APL 

Graphic 

Control Character 

76 

19 

1 or B 


62 or 42 

142 or 102 

1 or B 


79 

Bi 

oc or A 


61 or 41 

141 or 101 

oc or A 


7A 

msm 

n or C 


63 or 43 

143 or 103 

n or C 


7C 

174 


EOT 

04 or 14 

004 


end of transmission® 

7F 

177 


DEL 

18 

030 


cancel 

00 

000 

space§§ 


27 

047 

' 


00 

000 

space§§ 


60 

140 

0 


00 

000 

space§§ 


7B 

173 

{ 


00 

000 

space§§ 


7D or 7E 

175 or 176 

} or 1 — 


3D 

075 


IL or IDLE or NULl|| 

01 

001 


start of header 

3D 

075 


IL or IDLE or NULLJ® 

02 

002 


start of text 

3D 

075 


IL or IDLE or NULLS® 

03 

003 


end of text 

3D 

075 


IL or IDLE or NULL§§ 

05 

005 


enquire 

3D 

075 


IL or IDLE or NULL§§ 

07 

007 


bell 

3D 

075 


IL or IDLE or NULL§S 

OB or OC 

013 or 014 


vertical tabulate 








or form feed 

3D 

075 


IL or IDLE or NULl|§ 

10 

020 


data link escape 

3D 

075 

i 

IL or IDLE or NULLSs 

12 

022 


device control 2 

3D 

075 


IL or IDLE or NULL®® 

14 thru 16 

024 thru 


device control 4, 

i 


i 



026 


negative acknowledge. 








or synchronize 

3D 

075 


IL or IDLE or NULL§§ 

18 thru IF 

030 thru 


cancel, end of media. 






037 


substitute, 








file separator. 








group separator. 





' 



record separator, 








or unit separator 


^Shown with odd parity; odd parity is the default for this terminal class. (Unless PA=N or PA=I, the 
application program receives the same code as in normalized mode.) 

^^Each input line is assumed to begin in lowercase. Input characters are translated to lowercase ASCII 
characters unless prefixed by the UCS code. Once a case shift occurs, it remains in effect until another 
case shift code is received, the page width is reached, or the line is transmitted to the host computer. 
During output, case is preserved by insertion of case shift codes where needed. 

^t^Shown with zero parity (eighth or uppermost bit is always zero). 

^Not transmitted to the host computer after translation during input. 

®®Output translation only. 
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TABLE A-19. FULL ASCII NORMALIZED MODE APL CHARACTER SET 


b4 b3 b2 bj ROW COLUMN 


0 0 11 


0 1 0 


1 0 1 


0 1 1 


1 0 1 I B 


110 1 


1110 


— 128-Character Set- 

-96-Character Subset - 

64-Character Subset-^ 





0 

0 

0 

1 

1 

0 

1 

2 

DLE 

SP 

020 

040 

DCl 

• • or N/ 

021 

041 

DC2 


022 

042 

DC3 

: 

023 

043 

DC4 

$ 

024 

044 

NAK 

-i- 

025 

045 

SYN 

/N 

026 

046 

ETB 

' 

027 

047 

CAN 

( 

030 

050 

EM 

) 

031 

051 

SUB 

* 

032 

052 

ESC 

+ 

033 

053 

FS 


034 

054 

GS 

- 

035 

055 

RS 


036 

056 

US 

/ 

037 

057 




141 

161 

i 

P 

142 

162 

n 

r 

143 

163 

L 

- 

144 

164 

e 

1 

145 

165 

X 

U 

146 

166 

V 

CO 

147 

167 

A 

o • 

150 

170 

\ 

t 

151 

171 

O 

c 

152 

172 

—1 

{ 

153 

173 

□ 

> 

154 

174 

1 

} 

155 

175 

T 

1— 

156 

176 

o 

DEht 

157 

177 


'The graphic 95-character subset does not Include PEL; refer to Terminal Transmission Modes in the text. 
LEGEND : 

Numbers under characters are the octal values for the 7-blt character codes used within the network. 
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DIAGNOSTIC MESSAGES 


B 


This appendix lists the following categories of 
messages concerning network software: 

Application program execution errors 

Application program macro assembly errors 

Postprocessor errors and informative messages 


EXECUTION ERROR MESSAGES 

When the Network Access Method's execution time 
code detects an error, a diagnostic message is 
written in the application program's dayfile. The 
diagnostic messages issued by NIP are listed alpha¬ 
betically in table B-1. 

All fatal errors detected by NIP cause the applica¬ 
tion program to abort without the ability to 
reprieve itself from the abort. All fatal errors 
detected by AIP cause the application program to 
abort and permit the application to reprieve itself 
from the abort, but no further AIP calls are allowed 
after the abort occurs. 

The form of diagnostic message used by AIP and/or 
QTEM is partially determined by the library used to 
provide the routines for the execution run. If the 
routines are loaded from library NETIO, the only 
fatal diagnostic Issued is: 

NETWOEK APPLICATION ABORTED, RC=rc. 


where rc is a reason code from 01 through 99, with 
the significance indicated in table B-2. If the 
AIP and QTRM routines are loaded from library 
NETIOD, the same fatal diagnostic message is Issued, 
but a supplementary message explaining the reason 
code is Issued, as shown in the Message column of 
table B-2. The supplementary message begins with 
the name of the routine that detected the error. 

The additional Informative message: 

NAM VER. x.y - level 

is always issued at AIP NETON call processing 
completion. The numbers x, y, and level, respec¬ 
tively, Indicate the version number, variant, and 
PSR level of the AIP code used. 

ASSEMBLY ERROR MESSAGES 

When an application program uses the COMPASS macro 
version of the AIP calls, the assembly listing can 
contain the fatal error messages listed in table 
B-3. These macros are described in section 4. 

POSTPROCESSOR MESSAGES 

The debug log file postprocessor (DLFP) is used to 
process debug log files. During this processing it 
can issue the messages shown in table B-4. The 
debug log file postprocessor is described in sec¬ 
tion 6. 


TABLE B-1. APPLICATION PROGRAM DAYFILE NIP DIAGNOSTIC MESSAGES 


Message 

Significance 

Action 

Issued 

By 

ADDRESS OUT OF RANGE 

The application program specified 
an address of 0, 1, or a word outside 
of its field length on a NETPUT or 

NETGET type AIP call, or an AIP bug 
exists. 

Change the address and rerun 
the job. If an incorrect 
address cannot be found, con¬ 
tact a system analyst; a bug 
exists in AIP. 

NIP 

APP WORK LIST ADDR=0 

AIP has indicated that NIP should 
write its reply worklist at address 0. 
NIP cannot use this address. Either 
an AIP bug exists, or the application 
program has bypassed or destroyed its 
copy of AIP. 

Follow site-defined procedure 
to report and correct product 
or system problems. 

NIP 

APPLICATION IS NOT 
ALLOWED TO DO XFR 

The application attempted a call to 
the AIP routine NETXPR but is not 
validated for such a call. 

Remove the call to NETXFR. 

Only PTF and QTF are allowed 
to call NETXFR. 

AIP 
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TABLE B-1, APPLICATION PROGRAM DAYFILE NIP DIAGNOSTIC MESSAGES (Contd) 


Message 

Significance 

AcCion 

Issued 

By 

BAD AIP OPCODE 

AIP has passed an invalid operation 
code In a work] ist sent to NIP. 

Either an AIP bug exists, or the 
application program has bypassed 
or destroyed its copy of AIP. 

Follow site-defined procedure 
to report and correct product 
or system problems. 

NIP 

BAD WORD/ENTRY COUNT 

The number of words or entries in a 
worklist passed from AIP to NIP 
exceeded the maximum number permitted. 
Either an AIP bug exists, or the 
application program has bypassed or 
destroyed its copy of AIP, 

Follow site-defined procedure 
to report and correct product 
or system problems. 

NIP 

BKSP ERROR ON FILE 
xxxxxxx - AT=yyB, 

AIP encountered an I/O error while 
backspacing the specified file one 
record; yy is the abnormal termina¬ 
tion code returned by CIO (nonfatal). 

Check the abnormal termination 
code to determine what is 
wrong with Che file and then 
correct the problem. 

AIP 

EXTRA WORKLIST 

AIP passed a new worklist to NIP while 
NIP was still processing a previous 
worklist. Either an AIP bug exists, 
or the application program has by¬ 
passed or destroyed its copy of AIP. 

Follow site-defined procedure 
to report and correct product 
or system problems. 

NIP 

ILLOGICAL WORKLIST 

AIP has passed a worklist to NIP that 
contains more chan one NETWAIT or 

NETGET request. Either an AIP bug 
exists, or the application program 
has bypassed or destroyed its copy 
of AIP. 

Follow site-defined procedure 
to report and correct product 
or system problems. 

NIP 

INVALID APPLICATION 

NAME ON NETON 

The program attempted to access the 
network with an aname parameter that 
does not appear in the system 
validation file and/or COMTNAP. 

Correct the aname parameter 
and rerun the job. Check that 
the system validation file 
and/or C(MTNAP has been updated 
to Include the application's 
name. 

NIP 

INVALID MINACN/MAXACN 

ON NETON 

One or both of the indicated 
parameters was out of the range 
permitted for the installation. 

Change the parameters and 
rerun the job. 

NIP 

NONEXISTENT 

APPLICATTON ID 

NIP has no table entry corresponding 
to the process number AIP has passed 
to it to identify the applicatlon 
program. Either an AIP or NAM bug 
exists, or the application program 
has bypassed or destroyed its copy 
of AIP. 

Follow site-defined procedure 
to report and correct product 
or system problems. 

NIP 

NOT YET NETTED ON 

The application program attempted to 
use the network's resources before 
issuing a NETON call. If this message 
does not occur with the corresponding 

AIP message, either a bug exists in 

AIP, or the application program has 
bypassed or destroyed its copy of AIP. 

Change the program and rerun 
the J ob. 

NIP 

OVER 500 SUP MSGS 

QUEUED FOR APP 

The application program is not fetch¬ 
ing the asynchronous supervisory 
messages queued for it. When the 
queue in NIP reaches 500 supervisory 
messages, NIP aborts the application 
program and this dayfile message 
appears in the application's dayfile. 

Correct the program and rerun 
the j ob. 

NIP 
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TABLE B-1. APPLICATION PROGRAM DAYFILE NIP DIAGNOSTIC MESSAGES (Contd) 


Message 


Significance 


READ ERROR ON FILE 
xxxxxxx - AT=yyB. 


REWIND ERROR ON FILE 
xxxxxxx - AT=yyB. 


ROUTE ERROR ON FILE 
ZZZZZDN - AT=yyB. 


AIP encountered an I/O error while 
reading the specified file; yy is 
the abnormal termination code 
returned by CIO (nonfatal). 

AIP encountered an I/O error while 
rewinding the specified file; yy 
is the abnormal termination code 
returned by CIO (nonfatal). 

AIP encountered an error when it 
tried to route the ZZZZZDN file 
to the input queue; yy is the 
abnormal termination code returned 
by DSP (nonfatal). 


Action 


Issued 

By 


Check the abnormal termination 
code to determine what is wrong 
with the file and then correct 
the problem. 

Check the abnormal termination 
code to determine what is wrong 
with the file and then correct 
the problem. 

Check the error code to deter¬ 
mine why the route failed and 
then correct the problem. 


AIP 


AIP 


AIP 


SECURITY VIOLATION 


The application program has attempted 
to call NETON as a supervisory or 
validation program (CS, NS, or NVF). 


Change the program's origin 
type permission and rerun the 
job. 


NIP 


WRITE ERROR ON FILE 
xxxxxxx - AT=yyB. 


AIP encountered an I/O error while 
writing to the specified file; yy 
is the abnormal termination code 
returned by CIO (nonfatal). 


None. The file is returned to 
the system and a new one is 
created. 


AIP 
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TABLE B-2. APPLICATION PROGRAM DAYFILE AIP AND QTRM DIAGNOSTIC MESSAGES 


Reason 

Code 

Message 

Significance 

Action 

Issued 

By 

01 

thru 

28 


Reserved by CDC. 



29 

NETFUNC:REQDEST 

INVALID BEFORE 

NETON 

The application program 
issued the indicated call 
before It Issued a NETON 
call, or after it Issued 
a NETOFF call. 

Change the 
program and 
rerun the 
job. 

AIP 

30 

NETON: DUPLICATE NETON 
REQUEST 

The application program 
has called NETON twice. 

Change the program and rerun 
the job. 

AIP 

31 

NP$GET: REQUEST INVALID 
BEFORE NETON 

The application program 
issued a GET-type call 
before It issued a NETON 
call, or after it Issued a 
NETOFF call. 

Change the program and rerun 
the job. 

AIP 

32 

NPSPUT: request INVALID 
BEFORE NETON 

The application program 
issued a PUT-type call 
before It Issued a NETON 
call, or after it Issued a 
NETOFF call. 

Change the program and rerun 
the job. 

AIP 

33 

NETWAIT: request INVALID 
BEFORE NETON 

The application program 
issued the Indicated call 
before it Issued a NETON 
call, or after it Issued a 
NETOFF call. 

Change the program and rerun 
the job. 

AIP 

34 

NETDBG: request INVALID 
BEFORE NETON 

The application program 
Issued the indicated call 
before it Issued a NETON 
call, or after it Issued a 
NETOFF call. 

Change the program and rerun 
the job. 

AIP 

35 

thru 

39 


Reserved by CDC. 



40 

NETON: PREVIOUS REQUEST 
INCOMPLETE 

An AIP call other than to 
NETOFF or NETCHEK cannot 
be made while the program 
is in parallel processing 
mode and a previous AIP 
call has not been com¬ 
pleted . 

Relocate the Improperly 
placed NETON call and rerun 
the job. 

AIP 

41 


Reserved by CDC. 



42 

NP$GET: PREVIOUS REQUEST 
INCOMPLETE 

An AIP call other than to 
NETOFF or NETCHEK cannot 
be made while the program 
is in parallel processing 
mode and a previous AIP 
call has not been com¬ 
pleted. 

Relocate the Improperly 
placed GET-type call and 
rerun the job. 

AIP 

43 

NP$POT: PREVIOUS REQUEST 
INCOMPLETE 

An AIP call other than to 
NETOFF or NETCHEK cannot 
be made while the program 
is in parallel processing 
mode and a previous AIP 
call has not been com¬ 
pleted. 

Relocate the Improperly 
placed PUT-type call and 
rerun the job. 

AIP 
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TABLE B-2. APPLICATION PROGRAM DAYFILE AIP AND QTRM DIAGNOSTIC MESSAGES (Contd) 


Reason 

Code 

Message 

Significance 

Action 

Issued 

By 

44 

NETWAIT: PREVIOUS REQUEST 
INCOMPLETE 

An AIP call other than to 
NETOFF or NETCHEK cannot 
be made while the program 
is in parallel processing 
mode and a previous AIP 
call has not been com¬ 
pleted . 

Relocate the improperly 
placed NETWAIT call and 
rerun the job. 

AIP 

45 

NETOFF: NETOFF DURING 

FILE TRANSFER 

Application NETOFF while 
there is a file transfer 
still in progress. 

Relocate the Improperly 
placed OFF-type call and 
rerun the job. 

AIP 

46 

thru 

48 


Reserved by CDC. 



49 

NP$LOC: NO ENTRY WITH 
MATCHING ACN 

No entry in file transfer¬ 
ring table matching this 

ACN. 

Rerun the job. 

AIP 

50 

NP$ON: INVALID PROCESS 
NUMBER 

A bug exists in the oper¬ 
ating system or NAM. The 
process number assigned to 
the application program 
during processing of its 
NETON call was out of 
range. 

Follow site-defined 
procedure to report and 
correct product or system 
problems, 

AIP 

51 

NP$XFER: NW7. HAS 

OVERFLOWED 

The debug option code in 

AIP detected an error con¬ 
dition not caused by an 
application program AIP 
call. 

Follow site-defined 
procedure to report and 
correct product or system 
problems, 

AIP 

52 

NETFUNC: INVALID 

FUNCTION CODE 

USED 

A value other than 

1 is specified as 
the first parameter 
in the NETFUNC call- 

Correct the call by 
changing the value 
to 1. 

AIP 

53 

thru 

66 


Reserved by CDC. 



67 

NP$XFER: NIP NOT 

AVAILABLE AT A SCP 

The application program 
reprieved Itself after 
being aborted, but NIP has 
also aborted. The only 

AIP call that can be 

Issued after NIP aborts is 

a NETOFF. 

Change the application 
program reprieve procedure 
and re run the j oh. 

AIP 

68 

FETCH ILLEGAL FIELD 

MNEMONIC 

Either the field or value 
parameter in the indicated 
call was, not found. 

Correct the call and rerun 
the job. 

AIP 

69 

STORE ILLEGAL FIELD 

MNEMONIC 

Either the field or value 
parameter in the indicated 
call was not found. 

Correct the call and rerun 
the job. 

AIP 

70 

QTENDT: REQUEST INVALID 
BEFORE OTOPEN 

A QTENDT call is Illegal 
before a QTOPEN call or 
after a QTCIOSE call. 

Correct the statement 
sequence and rerun the job. 

QTRM 

71 

QTGET: REQUEST INVALID 
BEFORE QTOPEN 

A QTGET call is Illegal 
before a QTOPEN call or 
after a QTCLOSE call. 

Correct the statement 
sequence and rerun the job. 

QTRM 
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TABLE B-2. APPLICATION PROGRAM DAYFILE AIP AND QTRM DIAGNOSTIC MESSAGES (Contd) 


Reason 

Code 

Message 

Significance 

Action 

Issued 

By 

72 

QTPUT: REQUEST INVALID 
BEFORE QTOPEN 

A QTPUT call Is Illegal 
before a QTOPEN call or 
after a QTCLOSE call. 

Correct the statement 
sequence and rerun the job. 

QTRM 

73 

QTLINK: REQUEST INVALID 
BEFORE QTOPEN 

A QTLINK call is illegal 
before a QTOPEN call or 
after a QTCLOSE call. 

Correct the statement 
sequence and rerun the job. 

QTRM 

74 

QTTIP: REQUEST INVALID 
BEFORE QTOPEN 

A QTTIP call is illegal 
before a QTOPEN call or 
after a QTCLOSE call. 

Correct the statement 
sequence and rerun the job. 

QTRM 

75 

QTCMD: REQUEST 

INVALID BEFORE 

QTOPEN 

A QTCMD call is invalid 
before a QTOPEN call or 
or after a QTCLOSE call. 

Correct the statement 
sequence and rerun the job. 

QTRM 

76 

QTLEND: 

REQUEST INVALID 

BEFORE QTOPEN 

A QTLEND call is invalid 
before a QTOPEN call or 
after a QTCLOSE call. 

Correct the statement 
sequence and rerun the job. 

QTRM 

77 

QTSUP: REQUEST 

INVALID BEFORE 

QTOPEN 

A QTSUP call is invalid 
before a QTOPEN call or 
or after a QTCLOSE call. 

Correct the statement 
sequence and rerun the job. 

QTRM 

78 

thru 

79 


Reserved by CDC. 



80 

QTOPEN: DUPLICATE QTOPEN 

The application program 
attempted to perform 

QTOPEN a second time. 

Remove the extra QTOPEN 
statement and rerun the 
job. 

QTRM 

81 

QTOPEN: NIT NUM-CONNS 

FIELD IS ZERO 

The num-conns field in 
the network information 
table was zero when 

QTOPEN was called. 

Correct the table and rerun 
the job. 

QTRM 

82 

QTOPEN: NETON REJECTED 

The application program 
was not allowed to access 
the network. Either 
another application with 
the same name has accessed 
the network or the host 
operator has disabled the 
application from accessing 
the network. 

Rerun the job after 
contacting the host 
operator. 

QTRM 

83 

QTOPEN: NETWORK NOT 
AVAILABLE 

The network is not running 
or it temporarily does not 
have enough resources to 
allow this application to 
access the network. 

Rerun the job later. 

QTRM 

84 

QTSUP: SUPERVISORY 

MESSAGE REJECTED 

The application program 
attempted to send FCBRK, 
INTRAPP, CONACR, or CONEND 
using message code zero. 

Change the program to send 
these messages either by 
calling QTSUP with the 
proper message code or 
sending them by calling 
the proper QTRM routine. 

QTRM 

85 

thru 

94 


Reserved by CDC. 



95 

QTLINK: NO A-TO-A 

The application program 
requested connection to 
another application pro¬ 
gram when the A-to-A 
field is not set. 

Change the program to set 
the A-to-A field before 
the call to QTOPEN and 
rerun the job. 
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TABLE B-2. APPLICATION PROGRAM DAYFILE AIP AND QTRM DIAGNOSTIC MESSAGES (Contd) 


Reason 

Code 

Message 

Significance 

Action 

Issued 

By 

96 

thru 

98 


Reserved by CDC, 



99 

QTGET: NETWORK LOGICAL 
ERROR, TYPE n 

NAM has sent a logical 
error supervisory message 
to the application pro¬ 
gram; n is the reason code 
from the logical error 
supervisory message. The 
logical error is due to 
a QTPUT call with bad 
parameters stored in the 
network information table. 

Correct the parameter fields 
before issuing the QTPUT 
call. 

QTRM 


TABLE B-3. AIP MACRO ASSEMBLY LISTING DIAGNOSTIC MESSAGES 


Message 

Significance 

Action 

Issued 

By 

ERR FIRST PARAMETER MISSING 

At least one parameter is 
required in the AIP call that 
caused the error. 

Correct the call and reassemble 
the job. 

AIP 

ERR MUST BE LIST= 

A parameter is required after 
LIST= in the second calling 
format by the AIP call that 
caused the error* 

Correct the call and reassemble 
the job. 

AIP 

ERR NSUP ADDRESS MISSING 

Address of nsup word is not 
provided in the first or third 
calling format by the NETON 

AIP call that caused the error. 

Correct the call and reassemble 
the job. 

AIP 

ERR STATUS ADDRESS MISSING 

Address of status word is not 
provided in the first or third 
calling format by the NETON 

AIP call that caused the error. 

Correct the call and reassemble 
the job. 

AIP 

ERR MINACN ADDRESS MISSING 

Address of MINACN word is not 
provided in the first or third 
calling format by the NETON 

AIP call that caused the error. 

Correct the call and reassemble 
the job. 

AIP 

ERR MAXACN ADDRESS MISSING 

Address of MAXACN word is not 
provided in the first or third 
calling format by the NETON 

AIP call that caused the error. 

Correct the call and reassemble 
the job. 

AIP 

ERR HEADER AREA ADDRESS 
MISSING 

Address of application block 
header is not provided in first 
or third calling format by the 
NETGET, NETGETF, NETGETL, or 
NETGTFL AIP call that caused 
the error. 

Correct the call and reassemble 
the job. 

AIP 

ERR TEXT AREA ADDRESS 

MISSING 

Address of text area is not 
provided in the first or third 
calling format by the NETGET, 
NETGETF, NETGETL, or NETGTFL 

AIP call that caused the error. 

Correct the call and reassemble 
the job. 

AIP 
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TABLE B~3* AIP MACRO ASSEMBLY LISTING DIAGNOSTIC MESSAGES (Contd) 


Message 


Significance 



Issued 

By 


ERR TEXT LIMIT IS MISSING 

Address of text limit of block 

Correct the 

call 

and 

reassemble 

AIP 


acceptable is not provided in 
the first or third calling for¬ 
mat by the NETGET, NETGETF, 
NETGETL, or NETGTFL AIP call 
that caused the error. 

the job. 





ERR SECOND PARAMETER 

Second parameter is not pro- 

Correct the 

call 

and 

reassemble 

AIP 

MISSING 

vlded in the first or third 
calling format by the NETPUT, 
NETREL, NETSETF, NETSTC, 

NETWAIT, NETPUTF, or NETDBG AIP 
call that caused the error. 

the job. 





ERR THIRD PARAMETER MISSING 

Third parameter is not pro- 

Correct the 

call 

and 

reassemble 

AIP 


vided in the first or third 

the job. 






calling format by the NETPUTF 
or NETDBG AIP call that caused 







the error. 






ERR PARAMETER MISSING 

The parameter is not provided 

Correct the 

call 

and 

reassemble 

AIP 


in the NETSETP AIP call that 
caused the error. 

the job. 





ERR field ERROR IN 1ST 

The first parameter provided 

Correct the 

call 

and 

reassemble 

AIP 

PARAMETER 

in the NFETCH or NSTORE call 
that caused the error Is not 

the job. 






valid. The field parameter 
indicates the field in which 







the error occurs. 






ERR field ERROR IN FIELD 

The second parameter provided 

Correct Che 

call 

and 

reassemble 

AIP 

MNEMONICS 

in the NFETCH or NSTORE call 
that caused the error is not a 
valid symbolic field name. The 
field parameter indicates the 
field in which the error 

occurs. 

the job. 





ERR field ILLEGAL REGISTER 

The third parameter provided 

Correct the 

call 

and 

reassemble 

AIP 

NAME 

in the NFETCH call that caused 
the error is not a valid regis¬ 
ter. The field parameter 
indicates the field in which 
the error occurs. 

the job. 





ERR field ERROR IN BRD 

The third parameter provided 

Correct the 

call 

and 

reassemble 

AIP 

PARAMETER 

in the NSTORE call that caused 
the error is not a valid regis¬ 
ter. The field parameter 
indicates the field in which 
the error occurs. 

the job. 
















TABLE B-4. DLFP DAYFILE, ERROR, AND INFORMATIVE MESSAGES 


Message 


Significance 


Action 


Issued 

By 


BAD DEBUG LOG FILE 


BAD DIRECTIVE TABLE ENTRY 


DLFP COMPLETE 


DUPLICATE FILE NAME 


EMPTY DEBUG LOG FILE 


ERROR IN B DIRECTIVE 


ERROR IN BD= DIRECTIVE 


ERROR IN BT= DIRECTIVE 


ERROR IN C DIRECTIVE 


ERROR IN CN= DIRECTIVE 


ERROR IN DN= DIRECTIVE 


ERROR IN E DIRECTIVE 


ERROR IN ED= DIRECTIVE 


ERROR IN ET= DIRECTIVE 


ERROR IN F DIRECTIVE 


ERROR IN LE= DIRECTIVE 


ERROR IN N DIRECTIVE 


ERROR IN NM= DIRECTIVE 


ERROR IN P DIRECTIVE 


ERROR IN PF= DIRECTIVE 


ERROR IN PS= DIRECTIVE 


ERROR IN R DIRECTIVE 


ERROR IN SM= DIRECTIVE 


ERROR IN SN= DIRECTIVE 


DLFP did not process the debug log 
file because the content of the 
file was bad. 

DLFP detected an error in its 
internal tables. 


DLFP completed processing the 
debug log file, if any. 

The same file name was used on 
more than one parameter on the 
DLFP command. 

The debug log file was empty. 

B directive is not followed by 
keyword operator. 

Date is invalid or missing. 

Time is invalid or missing. 

C directive is not followed by 
keyword separator. 

Connection number is Invalid or 
missing. 

DN directive used Incorrectly. 

E directive is not followed by 
keyword separator. 

Date is invalid or missing. 

Time is Invalid or missing. 

F directive is not followed by 
keyword separator. 

Length is an invalid value or 
missing. 

N directive is not followed by a 
keyword separator. 

Number is invalid or missing. 

P directive is not followed by 
keyword separator. 

Hexadecimal number is invalid, not 
two digits, or missing. 

Hexadecimal number is invalid, not 
four digits, or missing. 

R directive is not followed by 
keyword separator. 

Number is invalid or missing. 

SN directive used incorrectly. 


Correct and rerun. DLFP 

Follow site-defined pro- DLFP 

cedure to report and correct 
product or system problems. 

None. DLFP 

Correct and rerun. DLFP 

None. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP 

Correct and rerun. DLFP' 
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TABLE B-4. DLFP DAYFILE, ERROR, AND INFORMATIVE MESSAGES (Contd) 


Message 

Significance 

Action 

Issued 

By 

ERROR IN T DIRECTIVE 

T directive is not followed by 
keyword separator. 

Correct and rerun. 

DLFP 

ERROR IN U DIRECTIVE 

U directive is not followed by 
keyword separator. 

Correct and rerun. 

DLFP 

ERROR IN X DIRECTIVE 

X directive is not followed by 
keyword separator. 

Correct and rerun. 

DLFP 

ILLEGAL CHARACTER 

The directive record contains a 
character that is not a letter, 
a digit, an equal sign, a 
comma, or a blank. 

Correct and rerun. 

DLFP 

ILLEGAL FILE NAME 

The file name contains characters 
other than letters and digits or 
it begins with a number. 

Correct and rerun. 

DLFP 

ILLEGAL PARAMETER 

DLFP does not recognize a 
parameter In the command* 

Correct and rerun* 

DLFP 

LOG FILE NOT CLOSED 

Debug log file was not closed 
correctly* Either NETOFF or 

NETREL was not called before 
the application terminated. 

Correct the application pro¬ 
gram for future executions, 
if possible. 

DLFP 

MULTIPLE COMMAS BETWEEN 
DIRECTIVES 

NO MESSAGES FOUND 

Two or more commas were used with 
no directive between them* 

No messages were found with the 
specified keywords* 

Correct and rerun. 

None. 

DLFP 

DLFP 

OVER 10 VALID CHARS BETWEEN 
KEYWD SEP 

The string of valid characters 
between the keyword separators 
was greater than 10 characters. 

A valid character is a letter, 
a digit, or an equal sign. 

Correct and rerun. 

DLFP 

PARAMETER FORMAT ERROR 

A parameter on the DLFP command 

Is not formatted correctly* 

Correct and rerun* 

DLFP 

PARAMETER SPECIFIED TWICE 

A parameter on the DLFP command 
appears more than once* 

Correct and rerun. 

DLFP 

UNRECOGNIZABLE KEYWORD 

A nonexistent keyword was used, or 
the first keyword did not begin 
in column one. 

Correct and rerun. 

DLFP 
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GLOSSARY 


C 


This appendix contains terms and mnemonics unique 
to the description of the software presented in 
this manual. It also contains terms whose inter¬ 
pretation within this manual is Intended to be more 
constrained or dlEferent from that commonly made. 
Some terms used in other manuals for the network 
software are included for the reader's convenience 
when reconciling terminology. 

Acknowledgment, Block - 

A message returned to the sender confirming the 
delivery of one block; referred to as BACK in 
CCP documentation. 

Address - 

A location of data (as in the main or micro NPU 
memory) or of a device (as a peripheral device 
or terminal). 

APL - 

A scientific programming language characterized 
by powerful operators and special graphic sym¬ 
bols. 

Application Block Header (ABH) - 

A single 60-bit word description accompanying 
every block passing between an application pro¬ 
gram and NAM. 

Application Block Limit (ABL) - 

The number of unacknowledged blocks a logical 
connection is allowed to have outstanding 
(queued by the network) at any one time. 

Application Block Number (ABN) - 

A field in the application block header. An 
application-assigned number used to identify a 
particular network data block. 

Application Block Type (ABT) - 

A field in the application block header defining 
the accompanying block as either data or super¬ 
visory, null or not null, and Indicating which 
block is the last block of a message. 

Application Character Type (ACT) - 

A field in the application block header defining 
the byte size and packing of text characters. 

Application Connection Number (ACN) — 

A number assigned by NAM to identify a particu¬ 
lar logical connection within an application 
program. 

Application Interface Program (AIP) - 

A group of routines that reside in the applica¬ 
tion program's field length. These routines 
buffer communication between the application 
program and the network, using the system con¬ 
trol point feature of NOS. 

Application List Number (ALN) - 

An application-program-assigned number used to 
identify a particular group of logical connec¬ 
tions belonging to the application program. 


Application Name (ANAME) - 

Up to seven 6-bit letters or digits (the first 
must be a letter) used to identify an applica¬ 
tion program. It is used by another application 
program, by a terminal operator when connection 
to the application is requested, and by the host 
operator to give commands. 

Application Program - 

A program resident in a host computer that pro¬ 
vides an information storage, retrieval, and/or 
processing service via the data communication 
network and the Network Access Method. Appli¬ 
cation programs always use the system control 
point feature of NOS to communicate with the 
Network Access Method. In the context of net¬ 
work software, an application program is not an 
interactive job, but rather a terminal servicing 
facility. A terminal servicing facility pro¬ 
vides terminal users with a specific processing 
capability such as remote Job entry from batch 
terminals, transaction processing, entry and 
execution of interactive jobs, and so forth. 
For example, the standard CDC interactive 
facility lAF makes terminal input and output 
appear the same to an executing program as file 
input and output; lAF is a network application 
program, but the executing program using lAF is 
an interactive job. 

Archetype Terminal - 

The specific terminal equipment possessing all 
of the attributes used as defaults for the 
definition of one terminal class. Each terminal 
class has a corresponding archetype terminal. 

Asynchronous - 

A transmission in which each information char¬ 
acter is individually synchronized by the use 
of start and stop bits. The gap between each 
character is not necessarily of fixed length. 

Asynchronous Protocol - 

The protocol used by asynchronous, 

teletypewriter-like devices. For CCP, the 
protocol is actually the set of protocols for 
eight types of real terminals. The NPU/ 
terminal interface is handled by the ASYNC TIP. 

Automatic Input - 

An output mode that prefixes up to 20 characters 
of the output message to the input reply. 

Automatic Login - 

The process whereby one or more of the Network 
Validation Facility login dialog parameters is 
supplied to NVF from the local configuration 
file. Parameters supplied through automatic 
login configuration of a terminal suppress 
prompting for the corresponding dialog entries 
and override any entries made from the terminal. 

Automatic Recognition - 

The process whereby the Terminal Interface 
Program identifies characteristics of a 
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terminal when the terminal's communication line 
becomes active. The Terminal Interface Program 
determines sub-TIP type and terminal class 
(and, for mode 4 terminals, the cluster and 
terminal addresses) by various methods for 
lines configured for automatic recognition. 
The Communications Supervisor then matches 
these parameters against the descriptions of 
specific terminals in the network configuration 
file; the terminal with the closest match to 
the empirically determined parameters Is 
automatically recog- nlzed as the terminal on 
the communication line. 

Base System Software - 

The relatively invariant set of programs in CCP 
that supplies the monitor, timing, interrupt 
handling, and multiplexing functions for the 
NPU. Base software also includes common areas, 
diagnostics, and debugging utilities. In 
CDCNET, the software that enables a CDCNET 
device Interface to function operationally. 

Batch Device - 

A device that is capable of conducting input 
only or output only operations. Card readers, 
line printers, and plotters are examples of 
batch devices. Batch devices are sometimes 
referred to as passive devices. 

Binary Synchronous Communications (BSC) - 

A communications protocol supported by the BSC 
TIP. This protocol connects IBM 2780 or 3780 
terminals to the NPU using half-duplex synchro¬ 
nous transmissions in a point-to-point mode. 
The terminals have batch devices which use 
EBCDIC code. Transparent data exchanges are 
permitted. The terminals are configured to 
have a virtual console (Interactive device). 
This is composed of a card reader for input and 
a printer for output. 

Block - 

In the context of network communications, a 
portion or all of a message. A message Is 
divided into blocks of one or more words (2 
bytes/word in the NPU) to facilitate buffering, 
transmission, error detection and correction of 
variable length data streams. Differing block 
protocols apply to the host/NPU and the NPU/ 
terminal interfaces. 

Block Acknowledgment - 

See Acknowledgment, Block. 

Block Header - 

See Application Block Header, 

Block Limit - 

The number of message blocks that can be 
awaiting delivery at any one time in either the 
host-to-NPU direction or the NPU-to-host direc¬ 
tion for a single device. 

Block Type - 

See Application Block Type. 

Break - 

A method employed by a terminal operator to 
Interrupt output or input in progress. 

Buffering - 

The process of collecting data together in buf¬ 
fers. Ordinarily, no action on the data is 


taken until the buffer is filled. Filled buf¬ 
fers include the case where data is terminated 
before the end of the buffer and the remaining 
space is filled with irrelevant codes. 

Byte - 

A group of contiguous bits. Unless prefixed 
(for example, a 6-bit byte), the term Implies 
8-bit groups. When used for encoding character 
data, a byte represents a single character. 


Cassette - 

The magnetic tape device in an NPU used for 
bootstrap loading of off-line diagnostics and 
(in remote NPUs) the bootstrap load/dump oper¬ 
ation. 

CDNA - 

Control Data Network Architecture; the network 
architecture designed by CDC to support the 
recommendations of the International Standards 
Organization's Open System Interconnection 
reference model. 

CDCNET - 

See Control Data Distributed Communications 
Network. 


CE Error Message - 

A message containing information concerning 
hardware and/or software malfunctions. 

Character - 

A coded byte of data, such as a 6-bit display 
code or 7-bit ASCII code. Terminals use a wide 
range of codes. Network products are respon¬ 
sible for translating between terminal codes 
and host codes. Unless otherwise specified, 
references to characters in this manual are to 
ASCII 7—bit byte characters. 


Character Type - 

See Application Character Type. 

Cluster - 

Mode 4 devices grouped by a common cluster 
address. Synonymous with terminal. 

Cluster Address — 

The hardware address of a cluster. This terra 
is used in several ways within mode 4 communi¬ 
cations documentation, as shown in table C-1. 

Communication Element - 

Any entity that constitutes a point of input 
to, or output from, the data communication net¬ 
work. This includes terminal devices, communi¬ 
cation lines, and application programs. 

Communication Line - 

A complete communication circuit between a 
terminal and its network processing unit. 

Communication Network - 

The portion of the total network comprising the 
linked network processing units. The communi¬ 
cation network excludes the host computer and 
terminals. 
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TABLE C-1. MODE 4 NOMENCLATURE EQUIVALENCE 


Networks 

Nomenclature 

Mode 4A 
Nomenclature 

Mode 4C 
Nomenclature 

Network processing 
unit 

Data source 

Control 

station 

Cluster address 

Site address 

Station 

address 

Cluster controller 

Equipment 

controller 

Station 

Terminal address 

Station 

address 

Device 

address 

Terminal 

Equipment 

controller 

Station 

Device 

Equipment 

Device 


Communications Control Program (CCP) - 

A portion of the network software that resides 
in a 255x Series network processing unit. This 
set of modules performs the tasks delegated to 
the NPU in the network. This software can 
include such routines as the Terminal Interface 
Program. 

Communications Supervisor (CS) - 

A portion of the network software, written as 
an application program; Che Communications 
Supervisor configures and controls the status 
of NPUs and all their communication lines and 
terminals. 

Configuration - 

See Network Configuration. 

Connection - 

See Logical Connection. 

Connection Number (CN) - 

A unique number assigned to each active device 
on a logical link. 

Constant Carrier - 

A communication line with a transmission carrier 
signal that remains on continuously; failure is 
reported if the carrier signal received remains 
off for a period of time that equals or exceeds 
a failure verification period. 

Contention - 

The state that exists in a bidirectional trans¬ 
mission line when both ends of the line try to 
use the line for transmission at the same time. 
All protocols contain logic to resolve the 
contention situation. 

Control Blocks — 

(1) The types of blocks used to transmit con¬ 
trol (as opposed to data) information; (2) 
Blocks assigned for special configuration/ 
status purposes in the NPU. The major blocks 
are line control blocks (LCB), logical link 
control blocks (LLCB), logical channel control 
blocks (LCCB), terminal control blocks (TCB), 


queue control blocks (QCB), buffer maintenance 
control blocks (BCB), multiplexer line control 
blocks (MLCB), text processing control blocks 
(TPCB), and diagnostics control blocks (DCB). 

Control Data Distributed Communications Network 
(CDCNET) - 

The collection of compatible hardware and 
software products offered by Control Data 
Corporation to interconnect computer resources 
into distributed communications networks. 

Controlled Carrier - 

A communication line with a transmission carrier 
signal that is raised and lowered with each 
block transmitted; failure is reported if the 
carrier signal received does not fluctuate in a 
similar fashion. 

Controlled Terminal - 

A terminal whose input can be started and 
stopped by the network software. When a ter¬ 
minal places data on a communication line only 
in response to a poll, the maximum input rate 
can be controlled by controlling the polling 
rate. Mode 4 terminals are controlled. 

Coupler - 

A hardware module resident in a front-end net¬ 
work processing unit. That coupler links the 
network processing unit to a host computer. 
Transmissions across the coupler use block 
protocol. 

Cross - 

The software support system for CCP. These 
programs, which are run on the host, support 
source code programming in PASCAL, macroassem¬ 
bler, and microassembler languages. The com¬ 
piled or assembled output of the Cross programs 
are in object code format on host computer 
files. The object code files are processed by 
other Cross programs and host installation pro¬ 
grams into a downline load file for an NPU. 

Cyclic Redundancy Check (CRC) - 

A check code transmitted with blocks/frames of 
data. It is used by several protocols. 

Data - 

Any portion of a message created by the source, 
exclusive of any Information used to accomplish 
transmission of such a message. 

Debugging - 

The process of altering a program to rid it of 
anomalies. 

Dedicated Line - 

A communication line that is permanently con¬ 
nected between a terminal and a network proc¬ 
essing unit. Contrast with Switched Line. 

DEFINE - 

An NDL statement that provides the macro-like 
capability of substituting an identifier in 
coding for a more complex entity. When the 
coding is processed, the identifier is inter¬ 
preted as if it had been replaced by the complex 
entity. Also, a NOS command that creates 
permanent files. 
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Destination - 

The device or application program designated to 
receive the message. 

Destination Node (DN) - 

The NPD node that directly interfaces to the 
destination of a data block. For instance, the 
DN of an upline block may be the host process 
which passes the block to the application pro¬ 
gram responsible for processing the block. 

Device — 

A separately addressable portion or all of a 
terminal. This term is used in various ways 
within mode 4 communications documentation, as 
shown in table C-1. 

Device Interface (DI) - 

The communications processor that CDC offers as 
its CDCNET hardware product. 

Diagnostics - 

Software programs or combinations of programs 
or tables which aid the troubleshooter in iso¬ 
lating problems. 

Direct Access File - 

In the context of NOS permanent files, a direct 
access file is a file that is accessed and 
modified directly. 

Downline - 

The direction of output information flow, from 
a host computer application program. 

Dump - 

In the context of CCP, the process of transfer¬ 
ring the contents of the NPU main memory, 
registers, and file 1 registers to the host. 
The dump can be processed by the Network Dump 
Analyzer in the host to produce a listing of 
the dumped information. 

Echo - 

The process of displaying a keystroke on a con¬ 
sole. Echoing can be done from the TIP, from a 
modem, or from the terminal itself. 

Echoplex - 

The process of returning received characters on 
a full-duplex line. Not all terminals on full- 
duplex communication lines are capable of echo¬ 
plex operation. 

File - 

A unit of batch data. Files are transferred 
between application programs and terminals by 
using PRUBs on the NPU's host side and trans¬ 
mission blocks on the NPU's terminal side. A 
file contains one or more records. Example: a 
card reader Job consists of a file containing 
the card image records of all the cards in the 
job deck. 

Format Effectors (FE) - 

Characters in an output data stream that deter¬ 
mine the appearance of data at the console. A 
format effector usually takes the form of a 
single character in the output line. For 
printing devices, the character is translated 
by the output side of the TIP into a combination 
of carriage returns, line feeds, or spaces. 
Similarly, FEs for displays can command new 
lines, screen clearing, or cursor positioning. 


Frame - 

A frame is a block of data sent across a high¬ 
speed link. It is composed of control bytes, a 
CRC sum, and (in some cases) data bytes in sub¬ 
block sequence. A sub-block can be a network 
data block or a part of a block. The frame is 
the basic communications unit used in trunk 
(NPU to NPU) communications and provides high- 
data density in bit-serial format over data- 
grade lines, as well as data assurance. 

Frames are transmitted as a sequence of bytes 
through the multiplex subsystem which uses a 
hardware-controlled frame on the input and out¬ 
put multiplex loops. 

Free-Wheeling Terminal - 

When a terminal can input at the discretion of 
the terminal user and has an input rate that 
cannot be controlled directly. Asynchronous 
terminals are free-wheeling. Contrast with 
Controlled Terminal. 

Front-End NPU - 

A network processing unit that directly inter¬ 
faces to one or more hosts. Synonymous with 
local NPU. 

Full Duplex (FDX) - 

IWo-way simultaneous transmission on a communi¬ 
cation line. 

Function Codes - 

Codes used by the service module to designate 
the type of function (command or status) being 
transmitted. Two codes are defined: primary 
function code (PFC) and secondary function code 
(SFC). Function codes are also used between NAM 
and the application programs in all supervisory 
messages. 


Gateway - 

Software that enables a CDCNET network to 
exchange information with a host or network 
that employes noncompatible architecture. 


Half Duplex (HDX) - 

Two-way alternating transmission on a communi¬ 
cation line. Normally a single set of data 
lines carry input, output, and part of the con¬ 
trol information. Contention for use is possi¬ 
ble in HDX mode and must be resolved by the 
protocol governing line transfers. 

Halt Codes — 

Codes generated by the, NPU when it is stopped 
by its software. These codes, which Indicate 
the cause of the stoppage, are contained in a 
CCP dump. 

HASP - 

A protocol based on the BSC protocol; it is used 
by HASP workstations. A workstation has both 
interactive and batch devices. The standard 
code of all HASP devices is EBCDIC; however, 
transparent batch data exchanges with the host 
are also permitted. The HASP TIP converts 
Interactive HASP data from EBCDIC transmission 
blocks to ASCII IVT blocks; it converts batch 
HASP data from EBCDIC transmission blocks to 
display code PRU blocks. 
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Header - 

The portion or portions of a block holding 
information about the block source, destination, 
and type. During network movement, a block can 
acquire several headers. For example, during 
movement of a block from a terminal to the host 
over an X.25 network, the block acquires the 
following headers: one at the terminal (also a 
trailer), one for the frame, one for the packet, 
and another for the host application program. 
Headers are discarded by the appropriate stage 
of processing, so that in this example, the host 
sees only the application program block header. 
Conversely, headers are generated and discarded 
as needed downline, so that the terminal sees 
only the terminal header (and trailer). 

Header Area (HA) - 

An area, usually one 60-bit word, within the 
application program containing the application 
block header for a NETPUT or NETPUTF call, or 
the area to receive the header for a NETGET, 
NETGETL, NETGETF, or NETGTFL call.- 

High-Speed Synchronous Line - 

A data transmission line operating at or above 
19200 b/s. These lines are normally used for 
local LlP/remote LIP transfers and for X.25 and 
HASP network transfers. 

Host - 

The computer that controls the network and con¬ 
tains the application programs that process 
network blocks. 

Host Interface Package (HIP) — 

The CCP program that handles block transfers 
across the host/local NPU interface. The HIP 
transfers control blocks and data blocks (IVT 
blocks or PRU blocks). 

Host Node - 

The node ID number of the NPU coupler that 
directly interfaces with a host computer. 

Host Operator (HOP) - 

The operator who resides at the system console, 
initiates NAM, controls NPUs and network- 
related host elements. The HOP may do all NPU 
operator functions as well as those functions 
unique to the HOP despite the exlstance of NPU 
operators. There can be only one HOP. Con¬ 
trast with NPU operator. 


Initialization - 

The process of loading an NPU and optionally 
dumping the NPU contents. After downline load¬ 
ing from the host, the NPU network-oriented 
tables are configured by the host so that all 
network processors have the same IDs for all 
network terminals, lines, trunks, etc. 

Input - 

Information flowing upline from tenninal to host 
computer. 


Input Parameter - 

A parameter in an AIP call that provides input 
to the AIP routine. An input parameter can be 
a constant, an expression, or a symbolic address 
for such values. Input parameters are not 
altered by the completion of AIP processing. 


Interactive Device - 

Any device capable of conducting both input and 
output, making it capable of dialog with the 
Network Validation Facility. Also known as a 
console device. An interactive device is serv¬ 
iced by an application program using the inter¬ 
active virtual terminal interface. Contrast 
with Passive Device. 

Interactive Virtual Terminal (IVT) - 

A block protocol format for interactive con¬ 
soles. CCP TIPs convert all upline interactive 
blocks to this format (exception: no trans¬ 
formations are made to transparent data except 
to put the data into block format). By this 
method, application programs in the host need 
only to be able to process interactive data in 
IVT format rather than in the multiplicity of 
formats that real terminals use. Downline mes¬ 
sages from the host to interactive devices are 
converted from IVT to real terminal format. 
IVT processing is controlled by the TIPs; the 
TIPs use some common IVT modules. 

Interface software - 

CDCNET software that enables a CDCNET network 
to exchange Information with a host or network 
that employs a noncompatible architecture. 

Layer software - 

CDCNET software that enables applications 
software, end users, terminals or workstations, 
and host computers to exchange information 
through a compatible set of protocols and 
Interfaces. 

Level - 

For logical records, an octal number 0 through 
17 in the system-supplied 48-blt marker that 
terminates a short or zero-length PRU. 

Line - 

A connection between an NPU and a terminal, or 
a group of terminals. 

Link — 

A connection between two NPUs or an NPU and a 
host. 

Link Interface Package (LIP) - 

The CCP program that handles frame transfers 
across a trunk; that is, across the connection 
between a local and a remote NPU. A LIP uses 
CDCCP protocol and interfaces on the local NPU 
side to the HIP. On the remote NPU side, the 
LIP Interfaces with- the appropriate TIP. In 
both local and remote NPUs, the LIP interfaces 
with the multiplexer subsystem for transfer 
across the trunk. 

List - 

A group of logical connections with the same 
application list number, which are linked 
together by NAM and treated as a single entity 
in NETGETL or NETGTFL calls. 

List Number - 

See Application List Number. 

Load - 

The process of moving programs downline from 
the host and storing them in the NPU main and 
micromemory. Loading of a remote NPU is accom¬ 
plished by the host through the use of the LIP 
in the local NPU. 
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Local Configuration File (LCF) - 

A file in the host computer system, containing 
information on the logical relationships among 
the service elements in the network. The file 
contains a list of the application programs 
available for execution in the host computer, 
and the users that require automatic login to 
them. This is a NOS direct access permanent 
file. 

Local NPU - 

An NPU that is connected to the host via a 
coupler. A local NPU always contains a HIP for 
processing block protocol transfers across the 
host/local NPU interface. Synonymous with 
front-end NPU. Contrast with remote NPU. 

Logical Connection - 

A logical message path established between two 
application programs or between a network 
terminal and an application program. Until 
terminated, the logical connection allows mes¬ 
sages to pass between the two entities. 

Logical Line - 

The basic message unit of a console device. 
See Physical Line. 

Logical Link (LL) - 

The portion of a logical connection defined by 
host node and terminal node ID numbers. A 
logical link is an error-free path across the 
network over which many separate logical con¬ 
nections are multiplexed. A logical link cannot 
traverse more than two NPUs. 

Logical Record - 

Under NOS, a data grouping that consists of one 
or more PRUs terminated by a short' PRU or zero- 
length PRU. Equivalent to a system-logical- 
record under NOS/BE. 

Loop Multiplexer (LM) - 

The hardware that interfaces the CLAs (which 
convert data between bit-serial digital and 
bit-parallel digital character format) and the 
input and output loops. 

Low/Medimum-Speed Voice-Grade Line - 

A line that operates at bit transmission rates 
at or below 19200 b/s. These lines character¬ 
istically connect individual terminals to an 
NPU or to an X.25 PAD service. 

Macromemory - 

The portion of 255x Series network processing 
unit memory that contains code Involved in data 
communication, such as the Terminal Interface 
Program. It is partly dedicated to programs 
and common areas; the remainder is buffer area 
used for data and overlay programs. Word size 
is 16 data bits plus three additional bits for 
parity and program protection. Memory is pack¬ 
aged in 16K and 32K word increments. 

Message - 

A logical unit of information, as processed by 
an application program. When transmitted over 
a network, a message can consist of one or more 
blocks. 

Micromemory — 

The micro portion of the NPU memory. This con¬ 
sists of 8192 words of 64-bit length. 1024 


words are Read Only Memory (ROM); the remaining 
words are Random Access Memory (RAM) and are 
alterable. The ROM memory contains the 
emulator microprogram that allows use of 
assembly language. 

Microprocessor - 

The portion of the NPU that processes the pro¬ 
grams . 

Mode 4 — 

A communication line transmission protocol that 
requires the polling of sources for input to 
the data communication network. Control Data 
defines two types of mode 4 equipment, mode 4A 
and mode 4C. Mode 4A equipment is polled 
through the hardware address of the console 
device, regardless of how many devices interface 
to the network. Mode 4C equipment is polled 
through separate hardware addresses, depending 
on the point each device uses to interface with 
the network. 

Modem - 

A hardware device for converting analog levels 
to digital signals and the converse. Telephone 
lines Interface to digital equipment via modems. 
Modem is synonymous with data set. 

Module - 

See Program. 

Monitor - 

The portion of the CCP base system software 
responsible for time and space allocation with¬ 
in the computer. The principal,monitor program 
is OPSMON, which executes OPS level programs by 
scanning a table of programs that have pending 
tasks. 

Miltlplex Loop Interface Adapter (MLIA) - 

The hardware portion of the multiplex subsystem 
that controls the multiplexing loops (input and 
output) as well as the interface between the 
NPU and the multiplexing subsystem. 

Multiplex Subsystem - 

The portion of the base NPU software that per¬ 
forms multiplexing tasks for upline and downline 
data, and also demultiplexes upline data from 
the CIB and places the data in line-oriented 
input data buffers. 


Neighbor NPUs - 

Two NPUs connected to one another by means of a 
tr unk. 

Network - 

An interconnected set of network processing 
units, hosts, and terminal devices. 

Network Access Method (NAM) - 

A software package that provides a generalized 
method of using a communication network for 
switching, buffering, queuing, and transmitting 
data. NAM is a set of interface routines used 
by a terminal servicing facility for shared 
access to a network of terminals and other 
application programs, so that the facility 
program does not need to support the physical 
structures and protocols of a private communi¬ 
cation network. 
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Network Address - 

The address used by block protocol to establish 
routing for the message. It consists of three 
parts; ON - the destination node, SN - the 
source node, and CN - the connection number. 

Network Configuration - 

The process of setting tables and variables 
throughout the network to assign lines, links, 
terminals, etc., so that all elements of the 
network recognize a uniform addressing scheme. 
After configuration, network elements accept 
all data commands directed to/through themselves 
and reject all other data and commands. 

Network Configuration File (NCF) - 

A network definition file in the host computer, 
containing information on the network elements 
and permissible linkages between them. The 
status of the elements described in this file 
is modified by the network operator in the 
course of managing the network through the 
Communications Supervisor. This is a NOS direct 
access permanent file. 

Network Definition File - 

Either of the two types of NDL program output 
files that determine the configuration of the 
network. This can be a network configuration 
file or a local configuration file. 

Network Definition Language (NDL) - 

The compiler-level language used to define the 
network configuration file and local configu¬ 
ration file contents. 

Network Definition Language Processor (NDLP) - 

The network software module that processes an 
NDL program as an off-line batch job to create 
the network definition files and other NDL pro¬ 
gram output. 

Network Element - 

Any configurable entity supervised or loaded by 
the Network Supervisor. A network element con¬ 
sists of any entity in the total network that 
is not a communication element; this term is 
usually applied to the data communication net¬ 
work entities comprising the NPUs and their 
linkages. 

Network Logical Address - 
See Network Address. 

Network Processing Unit (NPU) - 

The collection of hardware and software that 
switches, buffers, and transmits data between 
terminals and host computers. 

Network Supervisor (NS) - 

A portion of the network software, written as a 
NAM application program. The Network Supervisor 
dumps and loads the NPUs in the communication 
network. 

Node - 

A hardware or software entity that creates, 
absorbs, switches, and/or buffers message 
blocks. NPUs and host couplers are communi¬ 
cation nodes of the network. 

NPU Operator - 

The network operator who resides at a terminal 
and controls network elements such as NPUs, 
trunks, logical links, lines, and terminals. 


Contrast with Host Operator. Also, an operator 
using the offnet NPU console. 

Off-Line Diagnostics - 

Optional diagnostics for the NPU that require 
the NPU to be disconnected from the network. 

On-Line Diagnostics - 

Optional diagnostics for the NPU that can be 
executed while the NPU is connected to, and 
operating as a part of the network. Individual 
lines being tested must, however, be discon¬ 
nected from the network. These diagnostics are 
provided if the user purchases a network main¬ 
tenance contract. 

OPS Monitor - 

The NPU monitor. See Monitor. 

Output - 

Information flowing downline from the host. 
Output Buffer - 

Any buffer that is used to hold a downline mes¬ 
sage from the host. 


Packet - 

A group of binary digits, including data and 
call control signals, which is switched as a 
single unit. The data, control signals, and 
error-control Information are arranged in a 
specific format. 

Packet Assembly/Disassembly Service (PAD) - 

A definition of the procedures for the operation 
of an asynchronous terminal through a packet- 
switching network (PSN). 

Assembly: The accumulation of characters from 
an asynchronous device into data blocks for 
transmission via a PSN. Disassembly: The 
encoding of blocks for transmission to an 
asynchronous terminal. 

Packet-Switching Network (PSN) — 

A network that provides data communication 
service between various terminal and computer 
systems or networks. The PSN is usually 
licensed as a common carrier. 

Terminal Interface to a PSN is defined by the 
packet assembly/disassembly (PAD) service. PSN 
Interface with a NOS network is defined by the 
X.25 protocol. 

PAD SubTIP - 

A subTlP of the X.25 TIP that allows asynchro¬ 
nous ASCII terminals to communicate over a 
packet-switching network. 

Paging (Screen) - 

The process of filling a CRT display with data 
and holding additional data for subsequent dis¬ 
plays. Changing the paged display is terminal 
operator controlled if the page wait option is 
selected. 

Parity - 

A type of data assurance. The most common 
parity is character parity; that is, the sup¬ 
plying of one extra bit per character so that 
the sum of all the bits in the character 
(including the parity bit) is always an even 
(even parity) or odd (odd parity) number. 
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Pascal - 

A high level programmiag language used for CCP 
programs. Almost all CCP programs are written 
In the Pascal language. 

Passive Device - 

Any device incapable of conducting both input 
and output and therefore incapable of dialog 
with the Network Validation Facility. Batch 
unit record peripherals are typical examples of 
passive devices. Also known as a nonconsole 
device. Contrast with Interactive Device. 

Password - 

A parameter in the terminal operator's login 
procedure type-in, used for additional access 
security by the Network Validation Facility. 
This parameter does not appear in any super¬ 
visory messages. 

Peripheral Processor Unit (PPU) - 

The hardware unit within the host computer that 
performs physical input and output through the 
computer's data channels. 

Physical Line - 

A string of data that is determined by the ter¬ 
minal's physical characteristics (page width or 
line feed). Contrast with logical line, which 
is determined by a carriage return or other 
forwarding signal. 

Physical Link - 

A connection between two major network nodes 
such as neighboring nodes. Messages can be 
transmitted over active physical links. 

Physical Record Unit (PRU) - 

Under NOS, the amount of information trans¬ 
mitted by a single physical operation of a 
specified device. The size of a PRU depends on 
the device, as shown in table C-2. 


TABLE C-2. PRU SIZE 


Device 

Size in Number 
of 60-Bit Words 

Mass storage 

64 

Tape in SI format 

512 

with binary data 


Tape in I format 

512 

Tape in other format 

Undefined 


A PRU that is not full of user data is called a 
short PRO; a PRU that has a level terminator 
but no user data is called a zero-length PRU. 

Polling - 

The process of requesting input from hardware 
or software that only provides input on request. 
Polling is a concept of several network proto¬ 
cols and is used to avoid input contention. 
Mode 4 terminals are polled for input by the 
Terminal Interface Program servicing them; an 
application program polls all logical connec¬ 
tions for input, whether the logical connec¬ 


tions are with controlled mode 4 terminals or 
freewheeling asynchronous terminals. 

Port - 

The physical connection in the NPU through which 
data is transferred to/from the NPU. Each port 
is numbered and supports a single line. Sub¬ 
ports are possible but not used in the current 
version of CCP. 

Primary Function Code (PFC) - 
See Function Codes. 

Priority - 

The condition when traffic through the network 
is maintained preferentially for one or more 
devices out of all devices producing network 
traffic. Terminals with priority are the last 
devices for which network traffic is suspended 
when traffic must be temporarily stopped because 
the network is operating at capacity. Devices 
with priority receive preferential treatment of 
their input or output. 

Program Initiation Control Block (PICB) - 

A program initiation control block consisting 
of a sequence of commands that control NPU load 
or dump operations for a specific NPU variant. 
Several PICB's may exist on the network load 
file, each as a separate record with a unique 
NPU variant name as its record name. 

Protocol - 

A set of standardized conventions that must be 
used to achieve complete communication between 
elements in a network. A protocol can be a set 
of predefined coding sequences, such as the 
control byte envelopes added to or removed from 
data exchanged with a terminal; a set of data 
addressing and division methods, such as the 
block mechanism used between an application 
program and the Network Access Method; or a set 
of procedures used to control communication, 
such as the supervisory message sequences used 
between an application program and the Network 
Access Method. 

PRU Block (PRUB) - 

Physical record unit block. A block format for 
batch devices that is compatible with the host's 
PRU (batch file) handling capabilities. CCP 
TIPs convert all upline batch data to this 

format (exception: no transformations are made 
to transparent data except to put the messages 
into PRUBs). By this method, application pro¬ 
grams in the host need only to be able to 

process batch data in PRU format rather than in 
the multiplicity of formats that real terminals 
use. Downline messages from the host to real 

batch devices are converted from PRUB to real 

terminal format. PRUB processing is controlled 
by the TIPs with the help of the BIP. 

PRU Device - 

Under NOS, a mass storage device or a tape in 
SI or I format, so called because records on 
these devices are written in PRUs. 

Public Data Network (PDN) - 

A network that supports the interface described 
in the CCITT protocol X.25. 

Queues - 

Sequences of blocks, tables, messages, etc. 
Most network queues are maintained by leaving 
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the queued elements in place and using tables 
of pointers to the next queued element. Most 
queues operate on a first-ln-first-out basis. 
A series of worklist entries for a TIP is an 
example of an NPU queue. 

Random File - 

In the context of the NOS operating system, a 
file with the random bit set in the file envi¬ 
ronment table; individual records are accessed 
by their relative PRU numbers. 


Record - 

(1) A data unit defined for the host record 
manager; (2) a data unit defined for HASP work¬ 
stations. In either case, a record contains 
space for at least one character of data and 
normally has a header associated with it. HASP 
records can be composed of subrecords. 

Regulation - 

The process of making an NPU or a host progres¬ 
sively less available to accept various classes 
of input data. The host has one regulation 
scheme; the host and multiplex interfaces of a 
local NPU have another scheme; and the multiplex 
Interface to a neighbor NPU has a third regula¬ 
tion scheme. Some types of terminals (for 
Instance, HASP workstations) may also regulate 
data. Messages are classified as supervisory 
or service (highest priority) priority data and 
nonpriority data. Priority of data is estab¬ 
lished on a device-by-devlce basis through the 
PRI classification in NDL. 

Remote NPU - 

A network processing unit linked indirectly to 
a host computer through other network processing 
units. Contrast with local NPU. 

Response Messages - 

A subclass of supervisory or service messages 
that is a response to a supervisory or service 
message of the originator. Response messages 
normally contain the requested information or 
indicate that the requested task has been 
started or performed. Error or abnormal 
responses are sent when the responder cannot 
deliver the information or start the task. 

Return Parameter - 

A parameter in an AIP call that provides as 
input to the AIP routine the Identification of 
a location to which AIP should transfer infor¬ 
mation. This location Is within the application 
program's field length and outside of the AIP 
portion of that field length. A return param¬ 
eter cannot be a constant or a value in itself. 
Return parameters are always symbolic addresses. 
The time at which transfer of information from 
AIP occurs depends on whether the program is 
operating in parallel mode and whether use of 
the parameter is global to all AIP routines or 
local to the call in which it is used. 


Routing - 

The process of sending data/commands through 
the network to its destination (for Instance, a 
terminal). The network logical address (DN, 
SN, CN) is the primary criterion for routing. 
In the NPU, directories are used to accomplish 
the routing function. 


Sequential - 

A file organization in which records are stored 
in the order in which they are generated. 

Service Channel - 

The network logical connection used for service 
message transmission. For this channel, the 
connection number is 0. The channel is always 
configured, even at load time. 

Service Message (SM) - 

The network method of transmitting most command 
and status information to/from the NPU. Service 
messages use CMD blocks in the block protocol. 

Service Module (SVM) - 

The set of NPU programs responsible for proc¬ 
essing service messages. SVM is a part of the 
BIP. 

Short PRU - 

A PRU that does not contain as much user data 
as the PRU can hold, and is terminated by a 
system terminator with a level number. Under 
NOS, a short PRU defines EOR. 

Source - 

The terminal or host computer program that 
creates a message. 

Source Node (SN) - 

The node that interfaces directly to the source 
of a network data block. 

String - 

A unit of information transmission. One or more 
strings compose a record. A string can be com¬ 
posed of different characters or contiguous 
identical characters. 

Subfunction Code (SFC) - 
See Function Codes. 

Subport - 

One of several addresses in a port. In this 
release of CCP, subport is always equal to 0. 

Supervisory Message - 

A message block in the host not directly 
involved with the transmission of data, but 
which provides information for establishing and 
maintaining an environment for the communication 
of data, between the application program and 
NAM, and through the network to a destination 
or from a source. Supervisory messages may be 
transmitted to an NPU in the format of a service 
message. 

Switched Line - 

A communication line connected with one network 
processing unit but able to be connected to any 
one of several terminals via a switching mecha¬ 
nism, such as a dialed telephone line. 

Switching - 

The process of routing a message or block to 
the specified internal program or external 
destination. 

Symbolic Address - 

The abstract identification of an entity serving 
as a location from which or to which informa¬ 
tion can be transferred. A symbolic address 
can contain Information, but does not con- 
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stltute information. k symbolic address is an 
identifier represented in character form by the 
programmer and is equivalent to the concept of 
a variable in the terminology of some program¬ 
ming languages. In FORTRAN or ALGOL programs, 
typical symbolic addresses include array names, 
array element names, and variable names. In 
COMPASS, a symbolic address is equivalent to a 
label in a source code location field; a rela¬ 
tive address cannot be used as a symbolic 
address. In COBOL, a symbolic address is 
equivalent to a level 01 Data Description entry. 
In SYMPL, a symbolic address is equivalent to 
the name of an array or scalar item in a data 
declaration. 


Synchronous - 

A transmission in which character synchro¬ 
nization is achieved by recognition of a prede¬ 
fined sync character that precedes the block of 
data. 


Terminal - 

An entity, external to the data communication 
network but connected to it via a communication 
line, that supplies input to, and/or accepts 
output from, an application program. In the 
context of this manual, a terminal is each 
separately addressable group of devices com¬ 
prising a physical terminal or station. 

Terminal Address - 

The hardware address of a mode 4 console, a 
mode 4C printer or a 3780 card punch. This 
term is used in various ways within mode 4 com¬ 
munications documentation, as shown in table 
C-1. 

Terminal Class (TC) - 

An NDL parameter and supervisory message field 
value describing the physical attributes of a 
group of similar terminals, in terms of an 
archetype terminal for the group. 

Terminal Control Block (TCB) - 

A control block within CCP containing configu¬ 
ration and status Information for an active 
terminal. TCBs are dynamically assigned. 

Terminal Definition Commands - 

A group of commands that allow the operator at 
the terminal or a host application program to 
control some of the IVT transforms made by a 
TIP. 

Terminal Interface Program (TIP) - 

A portion of the Communications Control Program 
that provides an interface for terminals con¬ 
nected to a 255x Series network processing unit. 
The TIP performs character conversion to and 
from 7-blt ASCII, limited editing of the input 
and output stream, parity checking, and so 
forth. 

Terminal Name (TNAME) - 

A name of up to seven letters and digits known 
to the network and used to identify a device to 
the network operator. 

Terminal Node - 

The node number associated with an NPU that 
interfaces with a terminal. 


Terminal Operator - 

The person operating the controls of a terminal. 
Contrast with User. 

Terminal Servicing Facility - 
See Application Program. 

Test Utility Program (TUP) - 

A debugging utility that supports breakpoint 
debugging of CCP as well as other utility type 
operations such as loading and dumping. 

Text Area (TA) - 

The area within the application program that 
receives the message block text from a NETGET, 
NETGETF, NETGTFL, or NETGETL call, or contains 
the message block text for a NETPUT or NETPUTF 
call. 

Text Length in Characters (TLC) - 

A field in the application block header spec¬ 
ifying the number of character bytes of text in 
the message block. 

Text Length Maximum (TLMAX) - 

Maximum length in host central memory words of 
the supervisory message or network data block 
that the application program will accept for 
processing. 

Timing Services - 

The subset of base system programs within CCP 
which provide timeout processing and clock times 
for messages, status, etc. Timing services 
provide the drivers for the real-time clock. 

Trailer - 

Control information appended to the end of a 
message unit. A trailer contains the end-of- 
data control signals. Trailers can be generated 
by the terminal or by an intermediate device 
such as a frame generator. Not all headers are 
matched with trailers, although some devices 
split their control information between a header 
and a trailer. The trailer usually contains a 
data assurance field such as a CRC-16 or a 
checksum. Like headers, trailers are generated 
and discarded at various stages along a data 
block's path. 

Transparent Mode - 

A software feature provided by the Network 
Access Method and the network processing unit 
TIP. When transparent mode transmission occurs 
between an application program and a terminal, 
the Network Access Method does not convert data 
to or from display code, and the TIP does not 
edit the character stream or convert the char¬ 
acters to or from 7-bit ASCII code. When no 
parity is in effect for the terminal and trans¬ 
parent mode transmission occurs, all eight bits 
of the character byte can be used to represent 
characters in 256-character sets (such as 
EBCDIC). 

Trunk - 

The dedicated communication line connecting two 
network processing units. 

Trunk Protocol - 

The protocol used for communicating between 
neighboring NPUs. It is modified CDCCP proto¬ 
col that uses the frame as the basic communica¬ 
tions element. 


C-10 


60499500 U 



Typeahead (Terminal) - 

The ability of a terminal to enter Input data 
at all times. The ASYNC TIP supports typeahead; 
the X.25 TIP supports typeahead If It is pro¬ 
vided by the PSN. 

Upline - 

The direction of input flow to a host computer 
application program. 

User - 

That person or group of people who are the 
preparers and/or recipients of messages com¬ 
municated with an application program via the 
network. A user may interface with one or more 
terminals, or with no terminals. Contrast with 
terminal operator. 

User Name - 

The NOS validation file parameter entered by 
the terminal operator during the Network Vali¬ 
dation Facility log-in procedure. 

Virtual Channel (X.25/PAD) - 

A channel defined for moving data between a 
terminal and a host. Virtual channels are 
defined for the length of time that the terminal 
is connected to the PSN. 

Word - 

The basic storage and processing element of a 
computer. The NPU uses 16-blt words (main 
memory) and 32-blt word (internal to the micro 
processor only). All interfaces are 16-blt 
word (DMA) or in character format (multiplex 
loop interface). Characters are stored in main 
memory two per word. Hosts (CYBER series) use 
60-blt words but a 12-bit byte interface to the 
NPU. 

Some terminals such as a HASP workstation can 
use any word size but must communicate to the 
NPU in character format. Therefore, workstation 
word size is transparent to the NPU. 

Workllst Processor - 

Within CCP, the base system programs responsible 
for creating and queuing workllst entries. 

Worklists - 

Within CCP, packets of information containing 
the parameters for a task to be performed. 
Programs use worklists to request Casks of OPS 
level programs. Workllst entries are queued to 
the called program. Entries are one to six 
words long, and a given program always has 
entries of the same size. 

X. 25 Protocol - 

A CCITT protocol used by the packet-switching 
network. It is characterized by high-speed, 
framed data transfers over links. A PSN 
requires a PAD access for attaching asynchronous 
terminals. 

X.25 TIP - 

The CCP TIP that interfaces an NPU to a packet- 
switching network. 

Zero-Length PRU - 

A PRU that contains system information but no 
user data. Under NOS, a zero-length PRU defines 
EOF. 


MNEMONICS 

Following 
manual. 

is a list of mnemonics used in this 

ABH 

Application Block Header 

ABL 

Application Block Limit 

ABN 

Application Block Number 

ABT 

Application Block Type 

ACN 

Application Connection Number 

ACT 

Application Character Type 

AIP 

Application Interface Program 

ALN 

Application List Number 

AN 

Attribute Number 

ANAME 

Application Name 

APL 

A Programming Language 

ASCII 

American Standard Code for Information 
Interchange 

ASYNC 

Asynchronous 

AV 

Attribute Value 

BCD 

Binary Coded Decimal 

BIP 

Block Interface Package 

BLK 

Message Block 

BRK 

Break Block 

BSC 

Binary Synchronous Communication 

BT 

Block Type 

Bl, B2 

User-defined breaks 

CA 

Cluster Address 

CCITT 

Comlte Consultif International Tele— 
phonique et Telegraphique (an inter¬ 
national communications standards 
organization) 

CCP 

Communications Control Program 

CDCNET 

Control Data Distributed Communica¬ 
tions Network 

CDCCP 

CDC Communications Control Procedure 

CDNA 

Control Data Network Architecture 

CDT 

Conversational Display Terminal 

CE 

Customer Engineer 

CIB 

Circular Input Buffer 

CLA 

Communications Line Adapter 

CMD 

Command Block 
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CR 

Carriage Return 

HIP 

Host Interface Package 

CRC 

Cyclic Redundancy Check 

HO 

Host Ordinal 

CRT 

Cathode Ray Tube 

HOP 

Host Operator 

CS 

Communications Supervisor 

lAF 

Interactive Facility program 

DBC 

Data Block Clarifier 

ICMD 

Interrupt Command 

DBZ 

Downline Block Size 

ICMDR 

Interrupt Command Response 

DEL 

Delete character 

ICT 

Input Character Type 

DI 

CDCNET device Interface 

INITN 

Initialization Block Acknowledgment 

DLFP 

Debug Log File Postprocessor utility 

INITR 

Initialization Block Request 

DN 

Destination Node 

ISO 

International Standards Organization 

DSR 

Data Set Ready 

IVT 

Interactive Virtual Terminal 

DT 

Device Type 

LCF 

Local Configuration File 

EBCDIC 

Extended Binary Coded Decimal Inter¬ 
change Code 

LF 

Line Feed 



LFG 

Load File Generator 

EC 

Error Code 

LIP 

Link Interface Package 

EOF 

End of File 

LP 

Line printer 

EOI 

End of Information 

MCS 

Message Control System 

EOJ 

End of Job 

MLIA 

Multiplex Loop Interface Adapter 

EOM 

End of Message 

MPLINK 

The 1700 Cross link editor 

EOR 

End of Record 

MSG 

End-of-message block 

EOT 

End of Transmission 

MTI 

Message Type Indicators (Mode 4 pro¬ 

ETB 

End of Transmission Block 


tocol) 

ETX 

End of Text 

NAK 

Negative Acknowledgment. Block 

FD 

Forward Data (block protocol) 

NAM 

Network Access Method 

FDX 

Full Duplex 

NCB 

NPU Configuration Block 

FE 

Format Effector 

NGF 

Network Configuration File 

FE 

Front End 

NDA 

Network Dump Analyzer 

FET 

File Environment Table 

NDLP 

Network Definition Language Processor 

FF 

Form Feed 

NIP 

Network Interface Program 

FN 

Field Number 

NLF 

Network Load File 

FS 

Forward Supervision (block protocol) 

NOP 

Network Operator 

FV 

Field Value 

NPU 

Network Processing Unit 

HA 

Header Area 

NS 

Network Supervisor program 

HASP 

Houston Automatic Spooling Program 

NVF 

Network Validation Facility 


Protocol 

ODD 

Output Data Demand (Multiplex sub¬ 

HDLC 

High-level Data Link Control 


system) 

HDX 

Half Duplex 

PA 

Parity 
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PAD 

Packet Assembly/Disassembly 

SYNC 

Synchronizing Element 

PDN 

Public Data Network 

TAA 

Text Area Array 

PFC 

Primary Function Code 




TAF 

Transaction Facility 

PIP 

Peripheral Interface Program 

TC 

Terminal Class 

PL 

Page Length (IVT) 

TCB 

Terminal Control Block 

PPU 

Peripheral Processing Unit 

TIP 

Terminal Interface Program 

PRU 

Physical Record Unit 

TLC 

Text Length in Characters 

PRUB 

Physical Record Unit Block 

TLMAX 

Text Length Maximum 

PSN 

Packet Switching Network 

TNAME 

Terminal Name 

PW 

Page Width 

TO 

Timeout 

QDEBUG 

PASCAL Debugging package 

TTY 

Teletypewriter 

QTRM 

Queued Temlnal Record Manager 

TUP 

Test Utility Program 

RAM 

Random Access Memory 

TVF 

Terminal Verification Facility 

RBF 

Remote Batch Facility program 



RC 

Reason Code 

UA 

Unnumbered Acknowledgment (trunk or 
X.25 protocol) 

RGB 

Record Control Byte (HASP protocol) 

UBZ 

Upline Block Size 

ROM 

Read Only Memory 

U-Frame 

Unnumbered Frame (see UA and UI) 

RR 

Receive Ready (trunk or X.25 protocol) 

UI 

Unnumbered Information frame (trunk or 

RS 

Reverse Supervision (block protocol) 


X.25 protocol) 

RST 

Reset Block 

US 

Unit Separator 

RTS 

Request to Send 

XBZ 

Transmission Block Size 

SAM-P 

System Autostart Module Program 

X-OFF 

Stop character 

SARM 

Set Asynchronous Mode (trunk or X.25 
protocol) 

X-ON 

Start character 



XPT 

Transparent 

SCB 

String Control Byte (HASP protocol) 

X.3 

CCITT protocol for asynchronous ter¬ 

SFC 

Secondary Function Code 


minal access to a packet-switching 
network 

S-Frame 

Supervisory Frame (trunk or X.25 pro¬ 
tocol) 

X.25 

CCITT protocol for packet-switching 
networks 

SRCB 

Subrecord Control Byte (HASP protocol) 

X.28 

CCITT protocol for terminal access to 

STX 

Start of Text 


PSN/PAD 

SVM 

Service Module (for processing service 

X.29 

CCITT protocol for host access to 


messages) 


PSN/PAD 
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APPLICATION PROGRAM CALL STATEMENT SUMMARY 


D 


This appendix summarizes the formats of calls to 
AIP and QTRM routines. The general format of each 
routine Is listed alphabetically without description 
opposite the page number where the routine Is com¬ 
pletely described. 


COMPILER LEVEL (NETIO-RESIDENT 
OR NETIOD-RESIDENT) 


Call Format 

Page 

CALL NETCHEK 

5-16 

CALL NETDBG(dbugsup,dbugdat,avail) 

6-7 

CALL NETDMB(dumpld,ecs) 

6-9 

CALL NETFUNC(netfc,netpa) 

5-17 

CALL NETGET(acn,ha,ta,tlmax) 

5-4 

CALL NETGETF(acn,ha,na,taa) 

5-6 

CALL NETGETL(aln,ha,ta,tlmax) 

5-10 

CALL NETGTFL(aln,ha,na,taa) 

5-12 

CALL NETLGS(address.size) 

6-15 

CALL NETLOG(address,size,format) 

6-9 

CALL NETOFF 

5-4 

CALL NETON(aname,nsup,status.mlnacn, 
maxacn) 

5-1 

CALL NETPUT(ha,ta) 

5-7 

CALL NETPUTF(ha,na,taa) 

5-8 

CALL NETREL(lfn,msglth,nrewlnd) 

6-7 

CALL NETSETF(flush,fetadr) 

6-8 

CALL NETSETP(option) 

5-15 

CALL NETSTC(onoff,avail) 

6-15 

CALL NETWAIT(time,flag) 

5-14 

CALL NSTORE(array,field.value) 

4-11 

[lvalue=]NFETCH(array,field) 

4-11 

ENTER FORTRAN-X QTCLOSE 

8-34.3 

ENTER FORTRAN-X QTCMD USING 
cc,wsa 

8-27 

ENTER FORTRAN-X QTDBG USING 
dbugsup,dbugdat,avail 

8-38 


Call Format Page 

ENTER FORTRAN-X QTDMB USING 8-40 

dumpld.ecs 

ENTER FORTRAN-X QTENDT 8-32 

ENTER FORTRAN-X QTGET USING 8-30 

ta-ln 

ENTER FORTRAN-X QTLEND 8-33 

ENTER FORTRAN-X QTLGS USING 8-40 

wsa.slze 

ENTER FORTRAN-X QTLINK 8-31 

ENTER FORTRAN-X QTLOG USING 8-39 

wsa,size,format 

ENTER FORTRAN-X QTOPEN USING 8-26 

net-info-table 

ENTER FORTRAN-X QTPUT USING 8-29 

ta-out-acnj 

ENTER FORTRAN-X QTREL USING 8-38 

Ifn,msglth,nrewlnd 

ENTER FORTRAN-X QTSETF USING 8-39 

flush.fetadr 

ENTER FORTRAN-X QTSTC USING 8-40 

onoff.avail 

ENTER FORTRAN-X QTSUP USING 8-34 

smc,wsa 

ENTER FORTRAN-X QTTIP USING 8-31 

ta-out-acn£ 


ASSEMBLY LANGUAGE LEVEL 
(NETTEXT-RESIDENT) 


Call Format 


Page 

[label] NETCHEK 


5-16 

[label] NETDBG 

dbugsup,dbugdat, 
avail 

6-7 

label2 NETDBG 

dbugsup.dbugdat, 
avail,LIST 

6-7 

[ label1] NETDBG 

(LIST=label2 ] 

\LIST=reglster name) 

6-7 

[label] NETDMB 

dumpld,ecs 

6-9 

label 2 NETDMB 

dumpld,ecs.LIST 

6-9 
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Call Format 

Page 


[label1] NETDMB 

(LIST=label2 ] 

\LIST=reglster name[ 

6-9 

[label] NETGET 

acn,ha,ta,tlmax 

5-4 

label2 NETGET 

acn.ha,ta.tlmax, 

LIST 

5-4 

[label1] NETGET 

(LIST=label2 T 

[LIST=register nameJ 

5-4 

[label] NETGETF 

acn,ba,na,taa 

5-6 

label2 NETGETF 

acn,ha,na,taa,LIST 

5-6 

[label1] NETGETF 

(LIST=label2 ) 

[LIST=reglster name[ 

5-6 

[label] NETGETL 

aln,ha,ta,tlmax 

5-10 

label2 NETGETL 

aln,ba,ta,tlmax,LIST 

5-10 

[labell] NETGETL 

[LIST=label2 ] 

ILIST-register name) 

5-10 

[label] NETGTFL 

aln,ha,na,taa 

5-12 

label2 NETGTFL 

aln,ha,na,taa,LIST 

5-12 

[labell] NETGTFL 

(LIST=label2 ] 

[ LIST=reglster name) 

5-12 

[label] NETLGS 

address.size 

6-15 

label2 NETLGS 

address,size.LIST 

6-15 

(labell] NETLGS 

)LIST=label2 ] 

lLIST=register name) 

6-15 

[label] NETLOG 

address.size.format 

6-9 

label2 NETLOG 

address.size.f ormat. 
LIST 

6-9 

[labell] NETLOG 

)LIST=label2 ) 

\LIST=register name) 

6-9 

[label] NETOFF 


5-4 

[label] NETON 

aname.nsup,status. 
minacn.maxacn 

5-1 

label2 NETON 

aname.nsup.status. 
minacn.maxacn. LIST 

5-1 

(labell] NETON 

)LIST=label2 ) 

\LIST=regIster name) 

5-1 


Call Format 

Page 


[label] NETPUT 

ha .ta 

5-7 

label 2 NETPUT 

ha.ta.LIST 

5-7 

[labell] NETPUT 

(LIST=label2 i 

[LIST=reglster name! 

( 

[labell NETPUTF 

ha.na.taa 

5-8 

label 2 NETPUTF 

ha.na.taa.LIST 

5-8 

[labell] NETPUTF 

)LIST=label2 ] 

[LIST=register name] 


[label] NETREL 

Ifn.rasglth.nrewlnd 

6-7 

label 2 NETREL 

Ifn.rasglth. 
nrewlnd.LIST 

6-7 

[labell] NETREL ^ 

)LIST=label2 i 

1 LIST=reglster name] 

1 

[label] NETSETF 

flush.fetadr 

6-8 

label 2 NETSETF 

flush.fetadr.LIST 

6-8 

[labell] NETSETF ' 

(LIST=label2 1 

(LIST=reglster name! 

1 6-8 

[label] NETSETF 

option 

5-15 

label 2 NETSETP 

option.LIST 

5-15 

[labell] NETSETP ' 

(LIST=label2 1 

1 LIST=register name) 

5-15 

[label] NETSTC 

onoff.avail 

6-15 

label 2 NETSTC 

onoff.avail.LIST 

6-15 

[labell] NETSTC | 

LIST=label2 ] 

LIST=reglster name) 

6-15 

[label] NETWAIT 

time.flag 

5-14 

label 2 NETWAIT 

time.flag.LIST 

5-14 

[labell] NETWAIT | 

!LIST=label2 ] 

; LIST=reglster name) 

5-14 

[label] NFETCH 

array.field. )XJ] 

Uj) 

4-11 

[label] NSTORE 

array,field=value 

4-11 
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3-59 


Data 

Binary character A-1 
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End-of-line character (EL) 2-5 

End-of-record (EOR) 6-1 

EP command 3-60 

ERR/LGL/R 3-80 

Error reporting 3-79 

Execution time errors B-1 

Expand utility 1-8 


FA command 3-60 
Family name 3-11 
Fatal errors 6-6, B-1 
FC/ACK/R 3-36 
FC/BRK/R 3-38 
FC/INACT/R 3-30 
FC/INIT/N 3-16 
FC/INIT/R 3-15 
FC/NAK/R 3-37 
FC/RST/R 3-39 
Field number (FN) 3-59 
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Halt codes C-4 

Hardware performance analyzer (HPA) 1-7 
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Inputing to single buffer (NETGET) 5-4 
Inputing to single buffer (NETGETL) 5-10 
Interactive device C-5 
Interactive Facility (lAF) 1-7 
Interactive Transfer Facility (ITF) 1-7 
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Logical-error message 3-79 
Logical line C-6 
Logical link 

Definition C-6 
Logical protocol 2-1 
Logical record C-6 
LOGIN 3-30.2 
LOGOUT 3-30.2 
Loop Multiplexer C-6 
Low/medium-speed voice-grade line C-5 
LST/FDX/R 3-35 
LST/HDX/R 3-34 
LST/OFF/R 3-33 
LST/ON/R 3-33 
LST/SWH/R 3-34 
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Managing CCP device characteristics 3-51 

Managing connection lists 3-31 

Memory requirements 6-17 

MESSAGE 6-3 

Message 

Blocks 5-4 
Definition 2-7, C-6 
Protocols 3-1 
Sequences 3-1 
Transmission 5-4 
Types 2-7 

Message control system (MCS) 1-7 
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4-14, 

8-30 

QTLEND statement 
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Special editing mode (SE) 3-ol 

Statistical file 6-15 

String C-9 

Subfunction code (SFC) C-9 
Subport C-9 
Supervisory message 

Asynchronous 2-36 
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Terminal class (TC) 1-14, C-10 
Terminal control block (TCB) C-10 
Terminal definition commands 
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